Among many other things, it explains how eliminating goto removes certain useful optimizations. In fact, I think it's hard even to think of some of the constructs that Knuth uses if you are only practiced in goto-less programming.
"Please don't fall into the trap of believing that I am terribly dogmatical about [the goto statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a single trick, by a simple form of coding discipline!"
I've loved what little EWD reading I have done. The two points highlighted here I read as:
1. The program structure should reflect the problem structure as closely as possible
2. Thinking of every possible case ("enumeratively") is much less powerful than abstract reasoning
To me the second point is where the power of functional programming lies. You express ideas in relatively small units with no side effects that are easy to fully reason about. When you express things clearly it just feels right. Special casing is possible in most functional languages, but it usually feels like a kludge.
Another excellent essay is EWD831, "Why numbering should start at zero", which was something I felt was intuitive once I got used to it, but couldn't articulate clearly. Reading his essay was soothing in the same way as scratching an itch.
I've never really agreed that numbering should start at zero (or at one), I think people use indices way too much and it gets in the way of clarity. I much prefer whole array or list operations with no fiddling with indices and off by one errors. I like Haskell's array API, for example. You can index by whatever is natural in each case and you can always get the whole list of valid indices for an array x by using "indices x". I think that's much nicer, and it's also what D is doing: instead of having a(n implicitly paired) starting and ending iterator to indicate a range of positions like the C++ library does, D's library uses a range object. Basically I'm saying you can represent a range of indices as a pair of indices, one pointing to the first valid position and the other pointing past the last valid one, but that's an implementation detail you don't need to expose, make a range abstraction and you'll be happier.
I should also point out that mathematicians don't number at zero unless there is some advantage (the default is to start at one), but more importantly, the preferred style in mathematical arguments is to avoiding fiddling with indices as much as possible (since it's so easy to mess something up working at such a low level of abstraction).
If all of my tools had performant implementations of this abstraction, I would just use them. Unfortunately, much of the time this abstraction is provided, it is significantly slower than fiddling with indices.
This is a good post, and it links to fundamentally good material.
Two additional things are useful to note.
The first is that he didn't pick the title "Goto considered harmful", the editor did.
The other thing is that as the article says, many think he is simply an academic. There was a period of his career where he worked for Burroughs corporation (remember, they invented virtual memory before IBM, but nobody believed it until IBM did) and he and three or for others wrote a compiler. That compiler had, in its lifetime, a total of three or four bugs. So there was certainly a practical side to him as well.
One success measure for academics is how long their ideas survive their passing. (As the Physicists perversely say, "The revolutions don't wait for the old professors to retire, they wait for them to die.") It's a testament to the deepness of EWD's ideas that they are still relevant in the field despite all that's changed.
http://pplab.snu.ac.kr/courses/adv_pl05/papers/p261-knuth.pd...
Among many other things, it explains how eliminating goto removes certain useful optimizations. In fact, I think it's hard even to think of some of the constructs that Knuth uses if you are only practiced in goto-less programming.