Don't confuse what Google publish at the AOSP with what they ship on the Nexus/Pixel devices: they're increasingly different, with AOSP increasingly dysfunctional. Heck, the initial release of Android 7 for the 5X/6P at the AOSP wouldn't even compile because it had closed source compile-time dependencies.
And no, I really don't need anything that CM brings (I only switched from AOSP to CM because it was better supported on my tablet, CM actually had a developer while the AOSP guy was simply pulling the changes from the CM developer).
To have a large corporate overlord dictating how I use the device I "bought"
I see these same statements in the Linux Desktop world where everyone bitches about how All the Distro's are different, and how the Arch way is different from the Debian Way, and different from Red Hat, Canonical etc.
That is what I LIKE about Linux, that is what is LIKE about Android.
If i wanted a Corporate Overlord I would use an Apple or Microsoft commercial garbage
http://penguindreams.org/blog/android-fragmentation/
The problem is with all these ARM boards. As other comments have pointed out, vendors have tons of binary blobs and shim layers that link them to the kernel. Nvidia/AMD do this too with their video drivers, as well as Intel/Broadcom/Atheros with their Wi-Fi/BT chips. The difference on the PC platform is that it's standardized enough that you can run any kernel/distro on almost any x86/64 board and it will boot and give you a console.
Android vendor kernels are patched to hell, duct tape, just enough crap to get to production style software. They don't submit patches upstream because their code is often junk. ARM SoC are also all incredibly different.
You can download x86/64 versions of Debian, Gentoo, Void, Slackware, whatever and it will at a minimum boot on any PC hardware made in the past few years (probably even a Pentium if you use a 32-bit distro). Not all your hardware will work, but it will at least boot. ARM makes no similar guarantees. Cellphones don't support device trees, and even if they did the whole device tree system is a mess of its own.
Google has ultimate control over all vendors with the OHA. They can mandate standard kernels and drivers across devices. They won't though. There's simply too much money in requiring people to replace devices every two years.
To also add, some (most!) vendors make dirty hacks to the kernel source, as they maintain it as a standalone tree for the most-part.
Wired the headphone jack the wrong way around? Don't bother with a new PCB revision, as deadlines are too tight, and getting things perfect seems to have no place; just hack at the driver code in a messy way and change the outputs! It's not like you're ever going to really keep the device supported for a long time anyway!
So you get layered hacks - the SoC maker adds their own hacks because their production cycles are so short. Then the OEM gets the SoC and integrates it with their board, and due to their short development cycle, hacks around any issues they have too. End result is unmaintainable spaghetti of hacks and tweaks, which mainline wouldn't touch in a million years.
The other is creating userspace blobs that get passed void* from the kernel containing (kernel) internal data structures. The problem then comes about when the kernel changes those data structures.
The F/OSS 'community' has some of the most entitled folk on this blue planet - I'm yet to hear anyone suggest pet shelter volunteers work together on a mega-shelter instead of "wasting effort on duplicate roles".
But 10 different desktop environments are each solving the same problem 10 different ways, consuming 10 developers time, when a collaborative project would be able to reduce that by a huge factor and benefit everyone.
I would also suggest it's naive to think charity's don't have opinions about the duplication of effort. 10 storage animal shelters might very well waste funding and resources which could otherwise support 2 or 3 better equipped ones.
Most of the time, they don't merge because they don't want to.
For example, the guys working on Gnome3 wouldn't want to work on LXDE and vice versa. People want to scratch their itch. If I have a light computer (or have heavy tasks), I cannot run Gnome3. If LXDE didn't exist, I would go without a window-manager or would switch back to Windows.
And many who would look at an "ugly" DE like LXDE would switch back to Windows if they didn't have Gnome3.
Or benefit no one because you create a Desktop that no one likes because it is developed in a way to pisses everyone off
Gnome users do not like the KDE Experience
Awesome Users do not like the Gnome Experience
XFCE users do not like the Awesome Experiance
This is the reason these products exisit, and no it is not "duplicating efforts" any more than have different models of Cars is "duplicating efforts"
Do you really believe the automotive industry would be better off is all the Auto Manufacturers did away with all Models and simply made 1 car.
Nope, nobody believes that. Which is why any argument attacking that sort of thinking is nothing more than straw-man arguing.
What people believe is that some situations exist where fragmentation of effort produces far inferior results to coordinated efforts. The different factors that determine this are numerous and complex. Suffice to say, this sort of situation where fragmentation is indeed bad is common but far from universal in software.
The comments in this thread show some people insisting that this type of issue exists (and they are right) and some other people insisting on some dogma that fragmentation and competition are always fine (or something that sounds like that) and are arguing with straw men who think that coordination is always good and fragmentation is always bad.
Of what?
For one, Cyanogen has always refused to follow Google's guide lines and license terms. This is both what makes Cyanogen appealing to a small minority of users and also why there is absolutely zero chances why Google would ever fund this kind of effort.
The same argument applies to AOSP (cyanogenmod's upstream), but that hasn't stopped Google from supporting it.
So directly supporting an easy, installable downstream with bells-and-whistles like cyanogenmod would be a serious threat to google.
Or they are required to release those device's source code to (and pay for) the "communities" for the maintain the security updates.
If they don't do it, they are responsible to damage caused by those devices because of security issue or the customer's loss of data/privacy due to hacking by 3rd parties.
Similar to recent case where "food processor" company is liable if the blade is cracked into pieces into the processed food after a few years.
Just expand the warranty laws – security updates are fixing a manufacturing defect that makes the device unusable.