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.
Clock: https://android.googlesource.com/platform/packages/apps/Desk... - still worked on, identical
Browser: https://android.googlesource.com/platform/packages/apps/Brow... bug fixes only, but it was just a wrapper over webview. With chromium taking over webview any 3rd party/OEM browser app based on it essentially is a Chrome fork.
Calendar - https://android.googlesource.com/platform/packages/apps/Cale... Still worked on, identical except the built-in Google Calendar Content Provider/sync and alt icon
Contacts (People): https://android.googlesource.com/platform/packages/apps/Cont... - Still worked on, identical.
Gallery: https://android.googlesource.com/platform/packages/apps/Gall... - Still worked on/huge update in 4.4, identical.
Search: https://android.googlesource.com/platform/packages/apps/Quic... - Bug fixes, terrible 2.x style design, no Now.
Launcher: https://android.googlesource.com/platform/packages/apps/Laun... - Still worked on, doesn't include Google Now page or hotword detection
Music: https://android.googlesource.com/platform/packages/apps/Musi... Bugfixes, terrible 2.x design.
Settings: https://android.googlesource.com/platform/packages/apps/Sett... - Still worked on, identical
And to throw in three more essentials:
Keyboard: https://android.googlesource.com/platform/packages/inputmeth... - Still worked on. No Swipe input, identical otherwise
Camera: https://android.googlesource.com/platform/packages/apps/Came... - Still worked on. No Photosphere, identical otherwise
Email: https://android.googlesource.com/platform/packages/apps/Emai... - Still worked on, identical. Post-4.4 its design matches the Gmail app.
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.