That would be nice, but I'm not sure it's worth pushing 1.0 back a year or so, all other things being equal. I certainly wouldn't call trading a bit of prettiness for a lot of functionality "perverse."
If you mistake the call for Cocoafication for nothing more than a call for "prettiness", you're naturally going to end up missing why people care so much about it.
Java applications don't support a lot of deeper OS X features that make the platform so consistent. I have custom keybindings set up via the DefaultKeyBinding.dict mechanism that work pervasively throughout the OS, except in applications like AppCode that seem to think that their ease of coding trumps my consistency of platform and configuration. I think that kind of assumption is utterly broken and user-hostile, and it has nothing at all to do with "prettiness".
It was rgbrgb who brought up native GUI elements as the big reason for going Cocoa — I was just replying to his/her comment.
Anyway, like I told frou_dh, I do understand the benefits Cocoa offers. I've been a Mac user since 1985, Cocoa programmer since 2001, got the gold badge on Stack Overflow — believe me, I get it. But I also understand the benefits offered by JetBrains' existing IDE codebase. Engineering always involves tradeoffs. JetBrains' tradeoff may not align with your preference here, but the simple fact is, they now have a highly capable IDE shipping for OS X. Cocoa doesn't have anything particularly helpful to IDEs that would offset the cost of rewriting, so if they had gone with a total rewrite in Objective-C, it seems most likely that they would either not have anything shipping or they would have a pretty but half-baked product (or both).
It's true that not using Cocoa does hurt the product. But there are a lot of ways Cocoa apps can be broken and user-hostile too. The initial release of Xcode 4 was so broken that a lot of people downgraded after trying it for a week. It's still worse than Xcode 3 in terms of stability and responsiveness on average hardware. TextMate has always been Cocoa, but early releases were missing a lot of standard features because so much of the UI was custom code (as the standard Cocoa controls did not offer the functionality TextMate wanted).
So yeah, if AppCode were Cocoa, it wouldn't have all the UI problems it does now. It would have different problems. My point is just that which set of problems you'd rather have is a matter of personal preference. If you disagree with JetBrains' choice, then this is not the app for you, and that's OK.
I do see the problem with it not being Cocoa. The thing is, I also see a problem with throwing out huge swaths of your existing, mature codebase to make a minor project superficially nicer. They're both real problems, and which matters more to you depends on how strongly you adhere to the philosophy that "real artists ship."
When the iPhone came out, it didn't have cut and paste or any third-party apps. When OS X came out, it didn't even have DVD playback or CD burning and it was agonizingly slow. All of those decisions were far more "perverse" than leveraging an existing codebase to bring a new product to market. OS X as it exists today is the product of countless iterations on the promising-but-lousy OS X 10.0. To miss that fact is quite literally to miss what made OS X so great.
