As to your question of "For example, why would the Finder be Carbon if Carbon was just an interim API?" The answer has already been given by Apple: To show developers that significant applications can actually be done in Carbon. So the Carbon Finder was "proof of concept" and has nothing to do with whether writing the Finder in Carbon is a good idea. (It also helped Apple work out some of the bugs and deficiencies in Carbon.)
However, we can certainly see that Apple cannot continue a course where Cocoa and Carbon are on parallel development with all their own implementations. This is simply impractical, especially in the long term.
This means that either Apple has to find some way to jettison one of these approaches (a highly undesirable prospect for Apple, I would say [though, personally, I would love to see Carbon go the way of the dinosaurs]), or they have to find some way to utilize the implementation in one framework from another (reuse).
Unfortunately (for Apple, and for Cocoa developers), it is generally far easier to base an object oriented framework upon a sufficiently low level procedural one than it is to do the reverse (though you can wrap a very high level procedural framework upon a well factored object oriented one). This suggests that as things progress, we can expect to see either Cocoa based upon Carbon, or both based upon still lower level procedural frameworks (as is the case for much of the drawing and event handling).