So generally you'd agree a Swing GUI (or any other non-native GUI) isn't a problem too in itself.
JFileChooser is a bit of a corner-case in my opinion. Yes, JFileChooser sort of sucks, but you hardly ever see one. And if you consider we'll be saving our stuff more and more often on the web anyway, this will become even less of an issue.
File choosers appear in almost every software -- it's the standard means of loading and saving data. The fact that such a fundamental component is crappy is a big issue.
FileDialog (not Swing, which is what we're discussing) is indeed more OS compliant, though hardly any Java apps choose to use it over JFileChooser. Hell, even NetBeans seems to use the ugly JFileChooser.
There are some other minor quirks -- like not being able to search menu bar items on Mac (you need a bit of set up to get it working -- most developers won't ever bother), and the general feeling of the GUI being "off" (Mac software design is
generally extremely consistent from one app to the next).
Yes, Java/Swing applications start up slower. But QT nor Python is going to solve that if these applications are java for good reasons (like NetBeans, Eclipse or JVisualVM).
And besides, on my new laptop that has a nice and fast SSD, java startup-time isn't really an issue anymore. These performance increases you talk about work for java too, you know
There are plenty of IDEs not created in Swing (or Java for that matter). Eclipse uses SWT which is a great and very natural Java GUI, IMO.
VisualVM isn't exactly your average type of software -- although that, too, may have been better off not using Swing. The GUI is sluggish and unresponsive on my Mac. Granted, it's got a lot going on, but you wonder whether a more optimal GUI toolkit would help its situation...
Regarding H264 playback with JavaFX... Damn, that's nice.