It seems to me that when looking at IDE frameworks that support plug-ins the key point of the inquiry becomes not the age old X vs. Y IDE debate (my IDE is always better than your IDE) but about criteria about the plug-in development.
So, if I were in the market for an IDE framework within which to develop plug-ins or evaluating a 3rd party IDE with such a framework, some of my criteria would go beyond the established IDE features like syntax highlighting, multi-language support, code completion, etc. and start to include a different set of criteria:
What languages and technologies are required to develop plug-ins? For some using Java to build plug-ins for Java IDEs is a boon but in other contexts a scripting language might be preferable for its accessibility. Does the plug-in API require a sophisticated understanding of OO, patterns, etc. This can be very powerful but also daunting to initial efforts. That may not be a problem with a skilled and stable workforce but will be a problem if the plug-in fabricators are less skilled or have a high rate of turn-over.
What development tasks can be supported thru the plug-in API? Old-school editors like EMACS or CodeWright always had a scripting capability (the historical pre-cursor to plug-ins?) but these and early plug-ins were limited to coding support - syntax highlighting, code completion, etc. However, recent experience in plug-ins include features that support more broadly across the system development activities - to include testing, requirements management, etc.
How vulnerable would crafted plug-ins be to successive evolution of the underlying framework? Eclipse has attracted participants because even if Eclipse marches on to versions 3, 4, 5, etc. the plug-in crafter can still deploy their solution with their target version of Eclipse - also Eclipse has tried to sustain the API so that while the underlying framework improves it doesn't break older plug-ins. Such is not always the case. In the 90's there was a cottage industry of people building scripts/plug-ins for Rational Rose but if those scripts didn't work any longer as Rational upgraded from Rose 4 to Rose 98 to Rose 2000 etc. - it wasn't possible for the plug-in crafter to distribute older Rose products to support their plug-in. In the case of the Visual Studio product, the product (and the API) changed a lot during the version upgrades Studio 98 to .Net Studio 2003 to Studio 2005. Companies like Rational, CompuWare, RoqeWave, SlickEdit, etc. found this very disruptive... ended up encouraging some of them to move to Eclipse.
How well documented is the plug-in API, what training is available, and how many people are available that understand this API? Sustaining an inventory of plug-ins requires more than technology but also people that understand the technology. Is the API proprietary and/or require a license agreement to use? That limits the number of people one can recruit/hire to use that API. Are there published references (books, websites, etc.) on how to use the plug-in API? This has been a great boon to the popularity of NetBeans and Eclipse. Are any schools, training vendors, etc. turning out people skilled in the plug-in API? Again, Eclipse has benefited here from the work done at Carleton, Brown, CMU, etc and the same for NetBeans with some interesting projects out of UCB etc.
What other APIs are aggregated or exposed by the plug-in framework? For example, does the framework include accessibility to a graphics API (OpenGL ro DirectX) which might be useful when developing plug-ins with strong visualization features. Does the framework provide access to network services like ftp, http, smtp, etc.? How about access to the .Net framework or to the J2SE/J2EE? Is an kind of database support provided? What about XML processing? In all of these cases, does the API include these features or does the plug-in developer BYO technology with them depending upon the plug-in development language (Java, .Net, etc.) used (there are advantages to both).
These are just some of the topics that occur off the top of my head. But I think they are suggestive of the types of things to look for. If anyone has additional suggestions, I'd love to hear them.