I find it interesting that your comment (to me) seems to caution against "too much" syntactic highlighting, while the comparison screenshots in the README for the project you mention seem to indicate an extensive use of colors (compared to "traditional" highlighting, as per the readme).

On a personal note I do prefer the 2nd screenshot to the first (ie I prefer tree-sitter's highlighting than whatever they used to generate the "traditional" image).

In the end I think it comes down to colors being useful to highlight _meaningful_ differences between code snippets, be it semantic, syntactic, or whichever other distinction is useful to the person reading/editing the code at that time. As mentioned elsewhere in these comments, in a language that distinguishes between synchronous and asynchronous functions (à la async/await in Typescript or Python) it could very well be useful to have a different color for each.

Then again, if you're "just" opening up your code files to edit some string "constants" here and there, there's almost no point in having any other highlighting (at that moment/for that action/activity) than "what is string, what is not?". So the holy grail is some kind of highlighting that is aware of your intent (as in, why you are viewing/editing this piece of code), and can adapt to changes in said intent.