Maybe it's time to switch to QT.
I worked directly in the computer industry for decades, and have been in the audio business as a software engineer for over half a decade. I feel MOTU's pain, because we are dealing with platform issues here as well. And it's harder to have your concerns taken seriously by vendors when you're outside the core industry -- even Adobe has trouble with this!
My main app is written mostly in Java, partly because we thought it would insulate us from platform issues (at least to a degree), and I'm currently evaluating and working with Eclipse RCP in place of Swing (which I've used for years), for better native compliance and look-and-feel. I also have a long background in C and C++ based GUI tools, and a little bit of experince with QT (which is the main programming tool for most of our other apps).
Unfortunately, there is no panacea, and as these issues with C++ vs. Objective-C vs. MAS vs. AU vs. 32-bits vs. 64-bits vs. Carbon vs. Cocoa show, it is nigh impossible for a vendor to pick a set of tools, programming languages, etc., for scaling long-term product growth and a framework of reusable components for tiering multiple products, without eventually being bitten by a surprise of some sort that throws the whole strategy into a mess.
Having evaluated all of the available tools (including XML-based design and implementation tools), and having these past few weeks (since Leopard came out) brought my knowledge up-to-date on the internals, I am convinced that no decision could be made today that might not be regretted tomorrow. There just isn't enough of a mechanism in place in the industry to keep vendors on a standard even if they adopt it, and to convince them that everyone gains from having a common set of protocols that are abstracted beyond the choices that vendors make towards their own competitive advantage.
Contrast this with a mature industry like automobiles and it's startling how differently the two industries operate. By now computers are a mature industry, and if the main vendors continue to make life difficult for small third-party developers and end-user-application companies, I'm pretty convinced that more and more people will move away from computers and back to dedicated hardware (whether standalone hard disc recorders, or whatever else is appropriate to the field of endeavour).
Companies like MOTU are at least "in the business", whereas my own company is only "sort of" in the business (yet that is starting to change due to our growth in the area of DSP). In both cases, and in the case of most of the other vendors that many of us deal with for our main productivity tools, the resources just aren't there, nor are the "volume dollars" for these niche market tools, to support ripping out the core of a product or product suite every few years and doing it over. Nor is that productive towards the end goals of the business logic being implemented, or the needs of the consumer/customer.
It's easy to blame MOTU based on a simplistic view that Apple "warned" everybody that they should move to Cocoa. The real picture is a lot more complex. I wouldn't even know how to advise MOTU at this point, as I'm not 100% confident of my own decisions moving forward (until they have more time to play out), but I would still harbour a guess that a more platform-neutral toolkit or framework might be a good move, if things have to be done more or less from scratch anyway.
Although I'm none too eager to move to QT from Java myself (I switched to Java from C and C++ for a reason

), it now hosts Java including Swing and SWT/JFace. Amongst other languages, I think, but I didn't look in detail. A licensing fee is entailed, however. And also, QT, AWT/Swing, and SWT/JFace are all three currently based on Carbon when it comes to the Mac side of things (but at least the code will run fairly well on multiple platforms with only minor tweaking and slight configuration differences).
I didn't realise the DP code base was written in C++. Given the choice of C++ vs. Objective-C or C# (without Java, Ruby, or other languages entering the picture), I would be highly resistant to a vendor-specific programming language that ties in too big of an investment to assumptions about where one will be positioned in the industry in a few years time. Whether or not MOTU has plans to make DP dual-platform, I doubt they'd want to make this a more difficult proposition than it needs to be, by using Mac-specific Objective-C in Cocoa.
Objective-C is a well-designed language, and maybe it is more portable than I have come to believe, as Gnu's gcc can support it as long as it doesn't make use of some of the extra features (many of which were derived from Smalltalk's messaging facility). My experience with languages that are tied too closely to a hardware manufacturer (Java being an exception, outside of the poorly-designed event model of the Swing GUI toolkit), is that they tend to move forward in ways that often involve major rewrites -- unlike languages that are maintained by standards committee and which are used widely on all platforms (C, C99, C++, Java, Perl, Python, even FORTRAN, etc.).
We ran into some of the dreaded single-vendor programming language issues here when Delphi (which is based on ObjectPascal) kind of fizzled out and the tools stopped being supported (which meant that system/platform updates were at risk of eventually breaking the code). That was when we switched to QT for at least some of our applications. Delphi came from Borland, who sort of "went away" a few years back. Apple is not going away anytime soon, but still developers are at their whim if they decide to switch out technologies from ObjectiveC to something else and then force that on people.
FWIW, QT is vendor-specific (though widely used and partially open-source, as well as being the basis for one or more Linux GUI desktops such as KDE), and from version to version may make sweeping changes that require large code rewrites or modifications (though within the context of similar languages and tools). This is why I say there is no panacea (including Java, whose pitfalls and especially those of the Swing toolkit I am particularly familiar with).
I would not want to be in MOTU's shoes right now. They have a lot more at stake than we do and cannot shift gears as easily due to legacy, size of customer base, complexity and number of relationships with plug-ins, etc. I think it's fair to say that they have as difficult a task in adapting to Apple's evolving business model as companies like Adobe.