I don't think syntax highlighting is supposed to make any particular things stand out from "the rest" of the code. Every token of code is important at some part

I don't think syntax highlighting is supposed to make any particular things stand out from "the rest" of the code. Every token of code is important at some part of the process; otherwise it wouldn't be there. So there's no "rest" of the code to stand out from. Rather, the point of syntax highlighting (IMHO) is to accomplish three closely-related goals: 1. to insert obvious boundaries wherever the syntactic category of the lexeme stream changes, by changing color. This is why political maps color each country differently — it outlines what region of the map is in what country. (Note that, on its own, you don't need any given region to have any stable assigned color to achieve this effect. Political maps are often colored using the four-color theorem. Code could be too, if this is all you wanted to achieve.) 2. to create a scannable visual index, with the colors serving as syntactic categories, allowing your eyes to jump around the screen, or scan the file while scrolling, "by syntactic category." (That is: to re-anchor your eyes on a line that contains the identifier `foo`, without syntax highlighting, you'd have to either read the file line-by-line; or remember "where you left" the line by the relative shapes of the lines on-screen; or literally search for `foo` in your editor. But if `foo` is an identifier, and identifiers have their own distinct color, then you can glance around the screen for all the tokens that have been syntax-highlighted as identifiers — and then, as your eye lands on each identifier, you just check whether it says `foo`.) This is a reflex you pick up after reading a lot of code in a stable syntax-highlighting scheme; you might not even be aware you do this! 3. to induce in the user a sort of syntax-category<=>color synesthesia, where you can learn to spot problems in the code simply by noticing that something is the wrong color; or that you expected a token of a certain color to be present, but it's not (this is why parens+brackets+braces are often each given their own distinct highlight color). Basically the inversion of #2. You really only get any of these benefits to the degree that your syntax highlighting is [as the author puts it] "christmas lights diarrhea." You immediately lose benefit #1 as soon as any two syntactic categories are the same color. And you lose benefits #2 and #3 more and more as fewer things have their own distinct highlight colors. "Fully" colorized code might be ugly as hell to just read; but when you're actually writing it, it's ergonomic.