I'd like to point out a bit of an erronious assumption in this article. The two API's were never designed to have anything to do with each other. The reason that it's difficult for engineers to figure out the relationship between the two is that there isn't one. Yes, there are a few cases where Cocoa uses underlying Carbon services; this is a natural outgrowth of the fact that Cocoa runs across many operating systems (e.g. Windows), where it uses the native services, so when you run an OPENSTEP app on Windows, it'll use Windows print dialogs, etc.
But back to the main point -- the two API's aren't layered, and there is no master plan fitting them together. Cocoa provides all of the high-level and low-level functions that Carbon does, and more, just in a object-oriented, portable manner while Carbon is procedural and non-portable. They're just two completely different programming models, driven purely by the fact that many companies and developers would rather maintain an existing code base than face a rewrite. So if you've got tons of legacy code, or hate learning, stick to Carbon.
Cocoa is how a tiny company has produced a better web browser than a huge team at MS -- Cocoa apps are easily 10x easier to write than Carbon. I predict that Cocoa developers will out-perform Carbon developers, and that aside from a few markets where there's no real competition (i.e. people will always buy Windows, Photoshop, etc., no matter what any other company does), Cocoa-based products will beat Carbon in the marketplace, since the company will spend less money, produce higher quality software, and be more responsive to users' needs.
So, as many companies have proven, you have to compete with your own products (i.e. use Cocoa) or your competition will do it for you.