It's very easy to get wrong. Often, the syntax categorization itself is wrong because of parser issues (it's hard to get right in C IDEs. Java should be fine here).
Then, it's a question of what should be emphasized. Many syntax highlighters emphasize syntactic structure too much, making it hard for the programmer to concentrate on the content. I use Visual Studio for example, which is relatively unobtrusive (pastel colors) compared to e.g. the typical VIM color schemes. Visual Studio will color macro names, function names, variable names all in different colors - roughly purple, bronze, black. I just noticed it even colors function argument variables different from global variables/functions and member names. I don't think that's helpful for reading code. It's a distraction.
I certainly often find it distracting - it's notable that e.g. elvis' default highlighting, which mostly just slightly bolds {} and () and similar, doesn't bother me at all, though I get most of the same advantage out of 'showmatch' in vi.
(see my sibling comment for the fully verbose version)
So, most highlighting stuff frankly comes across to me as more like https://kassandry.net/misc/english_syntax.jpg than anything else - highlighting trivially inferrable structure at the expense of overall comprehension (note this entire comment is written under the assumption whatever the highlighting is doing it does perfectly, "bugs exist sometimes" is of course both trivially true and not the point).
Gentler colour schemes and things like e.g. rust highlighters that use a colour per lifetime are interesting and certainly I'm less likely to go out of my way to disable those.
The big problem I have though is that they are, by nature, highlighting at a specific granularity, and I'm generally not reading that way. My conceptualisation of code as I'm reding it jumps between the symbol, expression, statement, block, function, class levels all the time and it's very easy for the discontinuity when my granularity just changed and the colourisation didn't to snap me completely out of flow. Which is clearly an oddity of my brain, and unfixable absent focus-follows-mind, so oh well.
An interesting thing I've noticed is that having the code visually be a single artifact rather than heavily distinguished individual syntax artifacts means that I can often skim a file of code, have a "wait, that looked odd" moment, and find a bug that was completely unrelated to anything I was currently doing but had been hiding in there for quite some time - so, I mean, yes I'm weird, but there advantages to having one of this sort of weird around for review and debugging.
I agree I'm very much in a minority though I've encountered rather more (albeit still relatively very few) people who've found that synhi is helpful when -learning- a language, then when they're familiar they prefer turning it off at least some of the time to take advantage of the gestalt effects I was talking about.
This leads me to suspect that there might be people who'd enjoy this approach some of the time, later on, but never find out because it does absolutely take a while to get used to so "always use synhi" is a local maximum they don't escape - though even if my suspicion is correct, I'm making no claim there'd be that many people in that category either, just 'some'.
Certainly I've suggested to a few people over the years to try going without for a few weeks if they're curious, and of the ones who've tried a non-zero percentage have ended up either 'sometimes synhi' and at least one joining me in 'basically never synhi' - but they were all already experienced devs and weird enough to be willing to try it in the first place, so there's obviously going to be selection effects there.
It would be absolutely fascinating to run studies on a bunch of this - especially the "which bugs are easier to spot in which situation" part - but for the moment all I can really say is "yes, I'm definitely an outlier, but anecdotally sometimes usefully so".
(excuse the wall of text but hopefully it's enough to give you some idea)
