You state: "the primary myth that I am trying to debunk in the article is that either Cocoa or Carbon are the one true API for OS X."
A, potentially, laudable goal, but not, entirely, true---at least from an historic perspective (thus, it's subject to change as things evolve).
When you look at the history of this system, you see that BSD (and Mach services) and Cocoa (nee Yellow-Box, nee OpenStep) were there first. Java came next, and Carbon is the late comer (only added at the behest of developers that baulked at the idea of having to completely rewrite their old apps [highly understandable, to be sure]).
Unfortunately, the weight of legacy APIs is strong, so, now that the legacy Carbon APIs are here they are likely to be here for a long time (besides, Apple doesn't want to rehash the issues that lead to the inclusion of Carbon---only if, and when, Apple sees that few significant apps use Carbon will it go away). So now Apple is having to deal with this situation.
The best they can do (without throwing out the heavy weight Carbon based developers, or the significant, potential, competitive advantage of Cocoa) is to make the two peacefully coexist, without draining their development resources with a long term parallel development program.
Their strategy will, almost certainly, be based upon code reuse (probably via a combination of basing Cocoa atop Carbon, when that makes sense, and factoring lower level code bases from both Carbon and Cocoa), developer migration (hence the sails pitch about Carbon for legacy and Cocoa for the future [but they'll carry Carbon forward so as not to anger the legacy developers]), and cross language tools (most notably the Objective-C++ compiler that was available in the NeXT era, but dropped early on with Apple---they are repenting this decision).
Unfortunately, basing Cocoa on procedural APIs (whether Carbon, or a factored, lower level procedural framework) will, probably, slow development and technological advances. However, with tools like the Objective-C++ compiler, perhaps this procedural overhead can be minimized. (That's my hope, anyway.)