I think plugin architectures are fast becoming a open source developer defence mechanism to keep the project focussed. Develop a plugin architecture just so you can say "but you can develop a plugin" if you don't like it, to keep it outside the door.
Well, yes. I don't see a problem here.
Example, from my experience. LeakView plugin was welcomed (and even taken over) by the team and is now the
official plugin
While Manual Docker is not welcomed. For obvious reasons of being too narrow. However it works for me and I'm using it (not relying on the next iteration of bugs in xxxxDocking module).
The end developer still has an option and control over what set of plugins are used.
Don't take any care of any plugins except the ones you care about, and even move them back into the core IDE (and/or synchronize their releases), so that they are vastly superior, but yet present them as showcases.
The team is interested to make IDE looks its best, right?
The compatibility with other plugins is only achieved through carefully maintained plugin API.
...and the ability to create plugins out of tree!
what does it mean?