It's interesting that Jetbrains refuses to leverage those language servers and writes their own parsers for every supported language.
That's their specialty, but I'm not sure it's all that relevant for users who prefer lightweight editors.
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.
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.)
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.
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.
Terminals are a highly productive environment ignored at your peril. Can only tell you GUI-only folks are not well regarded in the industry.