This has been an ongoing cycle for all of Android. First people complain about Android lagging behind iOS so Google starts moving their services to GSM so they can avoid having to send updates through manufacturers. Then people complain Google isn't open enough so they start baking it into ASOP which takes forever to rollout. On the cycle goes..
It doesn't have to be either or. Most of the AOSP apps have been basically abandoned. They could develop the AOSP Calendar app and also put a branded version in GSM. But they aren't doing that.
This has been thrown around a lot, but it's not really the case when you look into it. Going to through the 9 base apps of the CDD and comparing to Nexus:
Each of the omissions has either an obvious Google server dependency (Google Now) or possible patent liability angle (the Swipe keyboard functionality). Music and Search are the only two which really stick out.
But even with Music, there's an argument to be made about the opportunity cost of doing so. There's no immediate benefit in spending dev cycles prettying up the AOSP Music app when no consumer will see it since every major OEM (Samsung, HTC, Sony etc) already have their own. Any time they set aside to that is time they could have used to work on the terrible latency problems plaguing the underlying audio system, which actually does make a difference across the board.
The same applies to Search. It's much more effective to commit those dev cycles on the layers underlying it so that the whole ecosystem benefits. Few of the exclusive features of the current Google Search app make sense for a service agnostic device search app to have, which is the original role of that app plays (Google's OS X app of the same name had the same featureset: http://www.google.com/quicksearchbox/). Really there's no motive to subvert the order of things and promote web search over OS search in a OS search app unless you own a search engine like Google.
Which isn't to say it (and Music) shouldn't be updated, since they do serve as docs for 3rd party devs and OEMs, so not updating would have some indirect inverse effect on the quality of apps. But I can see why they haven't got around to it yet given their trajectory.
tl;dr the situation is more grey than black or white.
An alternative would be to use GSM as a shim, that just calls through to AOSP if the functionality is there, or fills in the functionality if it's not.
But I'm not seeing the advantage to Google of doing that - as everyone gets GSM if they go for the major phones.
There is one factor that causes what's going into GMS and what into AOSP, that the article conveniently glosses over:
Functionality in GMS requries server side support. It can be computational capacity or server-side dabatases (fused location with wifi and cell towers? Google caller id? Map tiles? Storage? Server side push? Cloud support for games? All of them require something on the other side of connection).
Unless someone is willing to step in and provide this, there will be no AOSP equivalent.
Launcher certainly does - where do you think that Google Now prepares it's data?
Launcher without Google Now is part of AOSP.
Both Calendar and Email are available in AOSP, Play Store has their binary builds for those that for some reason do not have current Android version. They can have at least current apps.
Most GSM APIs are based around Google services and products, so some of the APIs don't really have an equivalent in AOSP. One of the other reasons why Google likes GSM over AOSP is the fact that there is much better control over versions of code out in the wild, whereas AOSP rollouts that come with updates to the phone propagate more slowly and inconsistently.
