The problem with this argument is that it's based on only a few of the most popular IDE's that the author happens to remember, but there were a bunch of others. For Java, you might remember NetBeans or VisualAge. There's a long tail.
Some of these IDE's supported more than one language. For example, VisualAge also supported C++ and SmallTalk. But each IDE supported a different set of languages with implementations of varying quality, they each had their own complicated plugin framework, and that's the N:M problem.
Even if it were just IntelliJ and Eclipse, that's still implementing support for a new language twice from the ground up, and you'll be doing it in Java both times, which is a lot of work for a team working on a new programming language.
I honestly think this is highly underrated as a reason. Teams working on a language want to program in that language. It doesn't really matter if it's complex, or they have to repeat the work for multiple IDEs. They love doing that. They will actually compete to do that (look how many posts on HN these days are just "$MUNDANE_TOOL written in Rust"). The main thing LSP did is it moved the boundary of the implementation to the other side of the language barrier.
Some of these IDE's supported more than one language. For example, VisualAge also supported C++ and SmallTalk. But each IDE supported a different set of languages with implementations of varying quality, they each had their own complicated plugin framework, and that's the N:M problem.
Even if it were just IntelliJ and Eclipse, that's still implementing support for a new language twice from the ground up, and you'll be doing it in Java both times, which is a lot of work for a team working on a new programming language.
You can look at the Wikipedia page to get a sense of how many different IDE's and languages there are out there: https://en.wikipedia.org/wiki/Comparison_of_integrated_devel...