Carbon and Cocoa have some interdependencies, but it is not the case one is built on the other; especially like MFC is built on Win32, or MacApp or Powerplant are built on the Mac Toolbox.
There are instances where Cocoa uses higher levels of Carbon --- the menu bar and the print dialog are the two examples. But this is really an implementation detail from an application developer point of view, who is using the respective APIs of each framework. The example provided above --- that the save dialog in Cocoa is Carbon --- is actually not correct; Cocoa has its own dialogs for save/open, font, color, spelling... But, again, an implementation detail.
The highest degree of sharing between Cocoa and Carbon is achieved by making the common services both need available at lower levels. That is why Carbon and Cocoa both appear as peers, in a layer above the ApplicationServices, CoreServices, and System boxes. These common services include APIs that are traditionally Carbon, traditionally Cocoa, and new --- examples are ATS, OpenGL, Quartz, CoreFoundation, LaunchServices... This approach allows high degree of code and data sharing, and interoperability. Where the two frameworks end up differing most is how they package and present these lower level APIs to the apps --- procedurally, or in an object-oriented fashion.
From a developer point of view, I think the best way to think of both is as described in the article --- Carbon for existing apps, and apps that need to run on Mac OS 9 and X both; Cocoa for new apps. How much they interdepend is an implementation detail, as each has their own, independent APIs, and as Scott Forstall said, Apple is committed to carrying both forward as the native frameworks of Mac OS X.