Kernels vary from manufacturer to manufacturer. A lot of those kernels come from the pure stock kernel line of sources found on CAF, what these manufacturers do is take those stock sources, modify them to suit based on the board/chipset used, also, implement their own drivers.
Take a good look around you, there's variations of touchscreens, variations of wifi chipsets, not to mention, accelerometer, sensors, batteries, compass, sound, graphics.
Taking one kernel source from for example HTC will not work on a Samsung, and vice versa.
The manufacturers are free to cherry-pick or out-source various bits that get incorporated into the circuit board. There is no hard or fast rules involved. Hence the lot of hacking/modifications to get the kernel to work properly.
You must not ever, compare to desktop Linux distribution kernels in which it has PCI, PCI-Express, SATA, VGA, SVGA, USB, Ethernet as they are a totally different ball-park game. The major differences with CentOS and with Android's Linux Kernel is this - ALL drivers are compiled either as modules or built-in, hence any Linux distribution will simply "work out of the box". Again, with desktop Linux distributions - you have one architecture - x86 hence one Linux kernel from say a Dell PC, can work out of the box on a Lenovo provided that the bog-standard drivers are compiled.
Don't forget, in the Android world, there's variations of the kernel built for specific ARM chipsets, such as ARMv6, ARMv7, there's TEGRA, there's EXYNOS, and they are binary incompatible with one another. Hence if a kernel is compiled for TEGRA, forget it, it will not work on ARMv7!
The reason some kernels on Android appear to be "broken" is down to the manufacturer. Some (Zte is one very good example) release a butchered source that may compile from source but fails to boot due to a missing driver that is not covered by the GPLv2 or GPLv3 licence. That's the problem, hence some hackers have to go scouring around github looking for some clues; some manufacturers, if not all, do comply. The current incarnation of Zte's source is purportedly to be 188.8.131.52, but in reality its actually 184.108.40.206 source base with a lot of modifications thus does not represent the true kernel source for 220.127.116.11!
This is where the manufacturers have to release their respective sources, not just out of being compliant with GPLv2 or later, but rather, for the community to be able to mod it, such as adding overclocking capabilities.
Hence there's hacking involved behind the scenes and a lot of messing about with drivers trying to get it to work, and its not easy to debug either.. Some drivers may be cross-licensed, BUT cannot be distributed depending on the clause and conditions as negotiated.
Thankfully, that's all changed now with kernel 3.x.x. line of sources, as Android drivers are now integrated into the mainstream sources. But there's a gotcha!
Try porting a 3.x.x. kernel to an existing handset that is about 12-18 months old; Not a snowball's chance in hell would it work, that's because, of the differing factors, the 3.x.x sources is vastly different to the 2.6.x source and would take a lot of hacking to get it working - I should know, have tried porting 18.104.22.168 source for the Zte Blade and failed.
Likewise, the latest kernel release 3.0.1 - when working on the ics4blade project over on Modaco, have made numerous attempts to port it but that's down to the simple fact that Zte made a very bad mess of the source which rendered porting nigh on impossible.