His example of how it is hard to read ordinary English with syntax highlighting is not very persuasive, because of the fundamental differences between written English and most programming languages.
English is a native human language. Humans are born with a capacity to efficiently learn one or more native languages. From very early in your life you start learning your spoken native language. An adult has from 20 to 100 years of exposure to the language, and all that time their brain has been improving its skill based on what they hear when others speak the language.
Written English is essentially a representation of spoken English. When you read written English, you read the words, and your brain processes them, analyzing their relations and identifying their roles.
For ordinary written English, then, I'd expect that reading would be most efficient when presented in a way that makes it easiest for us to recognize the individual words accurately and quickly. That gets them "inside" as fast as possible, in a form that lets our brains treat them similarly to heard words.
If we color the written text, I'd expect the coloring to slow down the raw rate of recognizing words, because of the distraction of the colors. The question then is whether having that extra tagging does anything to speed things up so as to overcome the slowdown in the raw rate.
I'd expect the answer to be "no", because at that stage of the process of reading, I don't think our brains care about parts of speech. That comes after the word is recognized and the stream of words is being processed like a stream of speech.
Note the above is all for "ordinary" English. I have found that when the English is considerably more complex than what we normally encounter, highlighting parts of it DOES make reading go faster.
For instance, consider law. One will sometimes find in statutes single sentences that take half a page or more, and have subclauses and intricate and complicated relations among the various parts of the sentence. When I was in law school, I had 5 or 6 highlighting markers of different colors, and I would use color to highlight the structure of the law. For instance, if a long sentence was structurally 4 subclauses connected by "or", I might highlight the "or"s between the clauses all in the same color.
In appellate court opinions, I might dedicate one color to highlight mentions of plaintiff in the original case, another to the defendant. I might use another to highlight cites that the court is agreeing with, and another for cites that the court is distinguishing this case from.
The key here is that the written English in these cases (no pun intended) was complicated enough that if it was spoken it would be hard to understand. You generally can't just read it through once and get it. To build up your understanding of it, you have to grasp the structure, and use that to guide you to grasping the meaning of the parts and how they relate to each other. You read it non-linearly, and the highlighting helps.
So now let's turn to programming languages. My contention is that programming languages are generally more like statutes and court opinions than they are like ordinary written English. Understanding a complex program is an iterative process that involves grasping the overall structure, then understanding small sections, which then improves your understanding of the big picture, which clears up some things about the smaller sections, and so on. You don't read linearly. You jump, just like when reading law. The syntax highlighting provides places to jump to.