LSP is a protocol and tree-sitter is a parser generator. They're kind of orthogonal concepts; a tree-sitter parser couldn't ever be used directly in place of an LSP server, but an LSP server may well make use of tree-sitter as a first step for extracting information from the code and keeping it in sync. If it doesn't it'll have to come up with some other way of parsing the code in any case, so I don't see how it could be said to be redundant or inconsistent.
Of course, tree-sitter's thing is how universal it is. There's parsers for tons of languages, and you can work with them all using the same API, though you're on your own for attributing semantic meaning. Most popular languages have language-specific tools (e.g. `libcst`) which are usually more powerful for that specific language, so they'd probably be better starting points for building a language-specific LSP server which I imagine is the common case.
The problem is using Treesitter (for syntax highlighting and "semantic movements") and an LSP at the same time. So if your language has a LSP, using Treesitter additionally is redundant at best and introduces inconcistency at worst.
I'm not talking about using Treesitter as the parser for the LSP.
> Most popular languages have language-specific tools
I'd say even less popular langauges like Coq^H^H^HRocq, Lean 4, Koka, Idris, Unison, ... have their "own" tools, I do not know of a language that uses a Treesitter parser in its LSP, but I do know about tools like https://semgrep.dev/ (written in OCaml) and Github's code search which use Treesitter.
LSP is a protocol and tree-sitter is a parser generator. They're kind of orthogonal concepts; a tree-sitter parser couldn't ever be used directly in place of an LSP server, but an LSP server may well make use of tree-sitter as a first step for extracting information from the code and keeping it in sync. If it doesn't it'll have to come up with some other way of parsing the code in any case, so I don't see how it could be said to be redundant or inconsistent.
Of course, tree-sitter's thing is how universal it is. There's parsers for tons of languages, and you can work with them all using the same API, though you're on your own for attributing semantic meaning. Most popular languages have language-specific tools (e.g. `libcst`) which are usually more powerful for that specific language, so they'd probably be better starting points for building a language-specific LSP server which I imagine is the common case.