From my experience, in language communities the people working on a language server (or on a similar tool but more restricted in scope, like a code completion tool), they prefer to work on the same language as they are targeting. As such, using OpenAPI and Java would not appeal to most of them.
Rather, in my view the big gain of abstracting OpenAPI from IntelliJ would be enabling ports of already-existing OpenAPI-based engines like the Go or Rust ones that I mentioned before. But there are also other ones for other languages: Scala, Groovy, etc., that are all licensed in some Eclipse-friendly license - and developed by Jetbrains.
So all those engines would be readily available for other IDEs if exposed under a LSP interface. One does wonder if such task would indeed be that easy/feasible technically: this would give away a lot of IntelliJ's value, since one of it's core strengths (the OpenAPI enabled engines), would not longer be tied to IntelliJ IDE itself. I'm not sure they would be that happy to keep paying developers to work on language engines that other IDEs would end up using for free.
Such experiment is not for me though (not on my volunteer time at least), I already have my hands tied to a lot of IDE related projects and tasks. Also, my main language of interest is Rust - for which I don't think the OpenAPI-based engine approach will be better than a native language server, given Rust's complexity (and given that the Rust team themselves have expressed interest in developing a language server).
But maybe it could be an idea for the Eclipse Ché guys. :) After all, the Go language is popular enough that one could consider it mainstream already, and it's also very focused on cloud and server-based apps, just like Ché infrastructure, so it seems it might be a good fit.
In any case, I guess we need to wait and have LSP mature and gain more popularity/support first of all.
