I think your understanding is mostly correct. A big part of LSP is helping you navigate and understand code, especially code written by other people. Jump to definition, find references, rename symbols, hover docs, autocomplete, etc. It’s basically a smarter way of exploring a codebase than grepping through files.
A lot of the demand for LSP also comes from people who grew up using IDEs. They’re used to having methods, types, parameter names, and documentation available right in the editor. It isn’t really about code generation, it’s more about reducing the need to constantly switch between your editor and documentation.
Personally, I think the value depends a lot on the language and ecosystem. For something like Java, C#, or TypeScript, where there are huge frameworks and libraries, LSP can be a massive productivity boost because nobody can remember every API.
With Crystal, though, I’ve never felt the lack of LSP as strongly as some people do. The standard library is relatively compact, the ecosystem is still fairly small, and the API docs are excellent. Most of the time I can just keep the docs open, do a quick search, and find what I need.
That said, I can understand why people working on larger Crystal projects want better LSP support. Features like jump-to-definition, find references, and reliable refactoring become more valuable as a codebase grows. If you’re spending all day moving around a large project, those little conveniences add up quickly.
As for why there’s less resistance to LSP than LLMs, I think it’s because LSP is mostly helping you understand code that already exists, while LLMs are trying to generate new code. People generally trust tooling that helps them navigate their code more than tooling that tries to write it for them.