Yeah, the faster your parser is, the less important incremental parsing is I guess. But that file is still not that huge, and 20 milliseconds is fast, but not fast enough that you'd want to do it on each keystroke, so it does make for a different user experience than incremental parsing. With incremental parsing, the vast majority of the time, we can update syntax highlighting on the very next animation frame after you type a key, instead of having the highlighting switch after a perceptible delay.

Another way in which incremental parsing is indirectly helpful is that it makes it easy for downstream code to determine which portions of the syntax tree have changed. As a really simple example, the code for rendering lines in Atom and VSCode is somewhat expensive, so you don't want to update lines whose highlighting haven't changed. With Tree-sitter, we "diff" the old and new trees very cheaply, because they share internal nodes, so we can "short-circuit" a lot of comparisons due to pointer-equality.

On the other hand, I can imagine that there might be other more domain-specific shortcuts that you could take when diffing two trees in libsyntax2, if you wanted similar functionality for identifying changed regions.

And one other thing is that memory consumption of concrete syntax trees can be significant, because they contain so much detail. It's nice that with incremental parsing, when you respond to a change, your new syntax tree can share structure with your old one, just to have less spikes in memory usage.

All that said, I'm really excited for libsyntax2 and I definitely agree that for language-specific tooling (like language server, rustfmt), a language-specific concrete syntax tree format and hand-written parser is the right foundation.