Shhhhhhh. We don't discuss that.
Before Carbon was announced, most of the big devs (and the small devs) threatened to simply not develop for MacOS X if they couldn't move their old code over. Can't really blame them... so they got Carbon, and the message that this was temporary.
That last bit freaked them out, again, and Apple had to go through a rather long period of placation, demonstrating that the devs could have more time to feel like they were using a peer API. Internally, there was also a lot of resistance to ditching the old MacOS Toolbox code completely, so Carbon did have some internal support.
Now, if you're going to ship the bloody API, and you're really not sure about it, and you want to show some very large (and very stubborn) large development houses that you do support their API of choice, what do you do? You write your own apps in it. It's that whole 'eating our own dog food' idea - by using the APIs to write your apps, you find the problems faster. By writing your apps in it, you tell others that you're not going to just drop it suddenly.
It hasn't been suddenly. It's been a decade. I would not at all be surprised to hear that Apple has Carbon-sanitized their apps. Remember the MacOS Toolbox -> Carbon helper app Carbonizer? It would be pretty damned simple to write an analog that helps you find the Carbon calls in your app, and map them to Cocoa equivalents. Actually *doing* the recoding isn't trivial, but a helper assistant isn't out of the question.
Think of it this way: When Carbon and Cocoa were announced, they shared basically no code between them. A developer used one, or the other, more or less. Carbon had certain Mac technologies that you couldn't access from Cocoa, so pretty quickly, many Cocoa apps also had some Carbon calls in them. Over time, this has changed - the functionality that was exclusively in Carbon has been pulled out and placed in the Core* APIs (CoreFoundation, CoreImage, CoreAnimation, etc). Carbon has been slowly but methodically gutted and has been becoming more of a legacy API shell over the Core* libraries. What previously required a Carbon call in a Cocoa app has been replaced with a Core* call. Also, to make them easier to use, much of the Core* stuff has a Cocoa wrapper as well, so a Cocoa dev can stick with a more 'pure' approach if they want.
When Carbon becomes an empty shell, but the assumptions about the runtime environment are holding back what can be done on the rest of the system... it's time to start shoving it off to the old code's home.
As to how this relates to Apple's apps: I'd wager that they are again eating their dog food by migrating the apps away from the Carbon API so it can be retired. If you look at how Apple rolls out dev technologies, they tend to hammer on them in house, privately, and only unveiling them when they have a) a solid implementation that's been tested, b) examples of how best to use the technology, c) anecdotes for marketing. I'd expect that, with an announcement of official Carbon deprecation, will come a set of tools to help migrate code away from Carbon, and an announcement that they've been using it in house on their own apps.