Even me, just as an user of the basic platform/workbench, I would gladly prefer to pay the price of the IntelliJ annual subscription if I doing so I did not have to worry about the issues/bugs mentioned before. Any competent developer would. The time/hassle it saves is worth much more than the subscription fee.
My second critique of Eclipse is a technical one. It is something that has become more apparent to me in the last year or so, as I've become more involved in contributing to Eclipse Platform code. In my opinion, Eclipse has historically been very bad at modularization of its components and libraries, and also really bad at re-using 3rd party ones. Intertwined with that, Eclipse has been too focused on the OSGi world and not that well adapted to the Maven world, which in Java at large is more popular, and has a much bigger ecosystem.
Take for example org.eclipse.text, the bundle containing IDocument and most of the document related code. This code does not conceptually depend on anything UI related, nor even on any other any major Eclipse Core component like Resources or Jobs, etc. . So it is quite conceivable that this code be re-used by other IDEs or editors. However, literally the most basic of Eclipse common code: org.eclipse.core.runtime.Assert, is in a bundle that requires not only OSGi but also Equinox specifically... #EpicFail
That is a horrible software practice, with regards to abstraction and modularization.
Yes, the Assert class, and others like org.eclipse.core.runtime.IStatus state that they can "be used without OSGi running", but a mere documentation comment is too brittle of a way to do things. Ideally we'd have such common code in a Maven bundle (which means it can be used in OSGi too), so that the Java community at large could easily use those libraries. And so that bundles like org.eclipse.text could also be made into pure Maven libraries too, without dependencies on OSGi and Equinox.
I can see why this happened historically: when IBM had loads of developers working in Eclipse, they didn't need to worry about the open source community at large, they had enough manpower to keep Eclipse going just by themselves. (plus, other ecosystems like Maven were perhaps not as mature or existent then as they are now - I know little about Maven history). But now IBM is gone, and we are paying the price of really hard adoption barrier for others in the Java community at large, because Eclipse code has been isolated in a niche.
Yet another example: org.eclipse.core.filebuffers. The
work I did on a patch for that plugin illustrated similar flaws. There
is lots of code there that should have be refactored in into a "
commons.io" library, completely independent of Eclipse code. Or better yet, it should have just used Apache
Commons IO.
I don't know if when this code was first written, Commons
IO existed already. But if it didn't, then the Eclipse team should have taken the initiative at the time to better refactor their code, and start their own Common Utils and Common IO if the Apache one didn't exist yet.
Another example is e(fx)clipse. It's a very interesting project, but one
wonders if they could have gotten even further ahead if Eclipse has
made their life easier. You see, there is a lot of "JFace" code that is
actually UI-independent, stuff like jface.text IRule, IPredicate and
document partition management code, or certain preference utilities -
however, all such code is in plugins that indirectly depend on SWT (!)
Even though their core functionality does not depend on anything UI. So
e(fx)clipse can't use it. (Or they can, but have to bundle SWT and bloat
their program footprint, or otherwise have other issues).
The recent announcement that Netbeans has been moved to the Apache Software Foundation shines some light on this criticism. I can imagine a different world were Eclipse IDE-independent code was much better abstracted, and was perhaps picked up by other projects like Netbeans. Or maybe it would have been easier for Eclipse to pick up code from Netbeans or IntelliJ. The IntelliJ open-source platform, from the quick look I took at it, seems to readily use Apache Commons code, Google libraries, etc. - smart of them. I'd guess it's a similar case with Eclipse Ché.
On the other hand Eclipse Platform and JDT, remains badly modularized, and we pay a big price for that. That's my take.