To me, that's the most fascinating, and entirely relevant (read: not self-serving or self-important) piece of what the author is talking about.
PHK wanted to do the sort of ground up work that would have taken ten years rather than 3.
Instead of spending 10 hypothetical years of their own time, doing the ground up work, they spent a small portion on HTTP/2.0. That portion is, in fact, smaller than the time spent on SPDY overall. So, how much standards-ing style work did they do? How much actual forethought was given besides making SPDY acceptable enough for a draft?
That's my takeaway.
The IETF mailing list archives are open if you'd like to see what 3 years of standardsing looks like. You can also go to the chair's blog (mnot.net) to read the evolution. Or Roy Fielding's presentations on Waka which were one of the early (2002) catalysts among the IETF-orbiters that lead to HTTP/2. http://gbiv.com/protocols/waka/200211_fielding_apachecon.ppt
Ultimately Waka was already a decade late, Google had SPDY which had some similarities and was already deployed, and people didn't want to wait another decade to build something no one might adopt. There were aspects of SPDY that needed changing to make it a true protocol standard rather than just a shared library, and a few features that out of rough consensus were changed.
That's how successful standards processes actually work - codifying what's already working, implemented in the field. Implementing a standard no one uses? See Atompub. See XHTML2.
SPDY was the only really viable option for the IETF to choose - it was running at scale and there was knowledge out there about deploying it and it's performance.
Although SPDY was the prototype, HTTP/2 isn't SPDY anymore it's evolved and moved on taking some of the concepts from SPDY and introducing it's own.
Given how long it took HTTP/1.1 to get ratified we suck at ten year standardisation processes.
If the IETF wanted a fresh look at HTTP, they would not have set such a short deadline for submissions.
It was evident from the start that this was about gold-plating & rubber-stamping SPDY, and people saw that and said so, already back then.
HTTP/2 isn't compatible with SPDY any more, but there is no significant difference between them, only a few deck-chairs were arranged differently in HTTP/2
The fact that people spend ages chewing the cud on a "clarification" of HTTP/1.1 has no impact on how long time it would take to define a HTTP/2 protocol.
Quite the contrary, HTTP/2 was a chance to jettison many of the horrors and mistakes that made the HTTP1.1bis effort so maddening.
You can see some of my thinking about what HTTP/2 should have been doing here:
That would be pushing HTTP/2 to irrelevancy the same way HTML5 (for good or for worse) pushed back on XHTML. Sad way to go but if need be ...