Presumably IDEA plugins have to be written in JVM languages, and use specific language-level bindings, and I would bet they're not very well decoupled from IDEA itself (which would make it really hard to write adapters to other editors).
Language servers are just that: servers, exposing a very unopinionated API. They run in a separate process, can be written in any language, and can even be hosted from any machine. That makes for a much more open and flexible standard.
I maintain that that would've been much harder to implement, for VSCode and for all other editors that followed. Among other issues, it would require a separate JVM process and some way for other languages to bind directly to JVM interfaces in that process, since most non-Java editors are not written in JVM languages.
If what you're suggesting is an LSP that wraps any given IDEA plugin and maps it to the LSP protocol, well, that can still be done (assuming it could ever be done) and would've still required the LSP protocol to be invented first.
On top of all that: you're welcome to re-use any code out there (in any language!) when writing an LSP. Nothing stops you from leveraging the bulk of an IDEA plugin, or whatever generic compiler utilities go into IDEA, when making your own LSP. I wouldn't say any work is wasted at all.
Language servers are just that: servers, exposing a very unopinionated API. They run in a separate process, can be written in any language, and can even be hosted from any machine. That makes for a much more open and flexible standard.