My understanding is that at least for the most popular languages, they were already doing more than the language server protocol would allow, so switching to language servers would be a downgrade.

That's their specialty, but I'm not sure it's all that relevant for users who prefer lightweight editors.

WebStorm definitely runs the TypeScript language service, but I believe they also have their own parser, completions, etc.

I think JetBrains is in a weird position. If they strictly rely on the official language server for everything, then they're not able to innovate or integrate with the many language-aware JetBrains features that go beyond what language servers typically do. On the other hand, the language server will always be a better source of truth for the basics since it's implemented by the language authors, and it requires no maintenance by JetBrains. My impression is they use a careful combination of both, but ideally it would be a unified implementation rather than two redundant implementations running side-by-side in different processes.

Why can they not extend the language server to meet their needs? Or if such feature is found useful generally for other editors too, then the language server should implement that than keep Jetbrains having some partial hacks on top of it.

The TypeScript language service is indeed extensible, but keep in mind that extensibility points can only get you so far, and JetBrains has spent the last 20 years putting a massive amount of work into a JVM-based code intelligence system. They can't just port all that to Node.js (and Go and every other language/runtime where language servers run).

Of course it would be great if the official TS language service included every imaginable IDE feature, but realistically it will always lag behind a team focused on exploring new ideas. JetBrains is going to want to experiment with new language-aware features, iterate on some of them, and throw out the ones that they aren't happy with. An open source tool shared by all editors isn't the right environment for that sort of experimentation. (They could fork the language service, though, which has its downsides but maybe is most reasonable here.)

the language server protocol doesnt support everything jetbrains does.

they can extend the server as much as they want, if the protocol doesn't support the additions, they'll be useless features unless they'll implement protocol extension, which could potentially be incompatible with the original... and they're back to the starting proposition.

I don't know if they "refuse" to leverage it. They have been building IDEs for a long time and have a toolchain for building parsers for an IDE. It would make sense for them to just use that. Besides, they were building the Go IDE before the LSP was mature.

very few languages implement the RLS well. For instance Rust does it, but its incomplete and very slow. I bought a quieter CPU fan specifically because of it!

It's more a function of language complexity than anything else. LSP for something like C, Java or TypeScript is not that hard, because the language is fairly straightforward to parse, and not ambiguous. But something like C++ or Rust, where you have to deal with templates/generics/traits/... and type inference starts getting gnarly. And something like JS or Python is hard because there are no static types at all, and you have to do inference.

But LSP itself doesn't really make it easier or harder. If you look at other code completion implementations (in IDEs that don't use LSP), they're usually at a comparable level, if they exist.

Have you used RLS recently? It’s improved quite a bit for me

Good. Great even. If the implementation is top notch, mantained and from the 1st party, why the hell not, but most of the times, language server implementations are half assed, slow, "kinda" working messes that are all but useless in the long run. The PHP language server implementations are a great example of this. A buch of broken, incomplete, underperforming projects maintained by a single person (or straight up abandoned). Compare that with Phpstorm and you have just compared a rusty tricycle with a spaceship.

Your "insightful" terminal comment is dead.

Terminals are a highly productive environment ignored at your peril. Can only tell you GUI-only folks are not well regarded in the industry.