I think the idea is that HTTP/1 is simple in the hello-world 5th-percentile-complexity case, which deceives people into thinking that it's also simple in the real-world 99.9th-percentile-complexity case, which it's not at all.

It's, like, simple in about 80-percentile-complexity case. But the rest 20% take 80% of the work (and re-architecturing). For example, 1xx responses break 1-1 correspondence between requests and responses. Then an "Upgrade" header may mean you need to turn a connection into a dumb byte pipe, ditto for "CONNECT" requests. Then there is a whole business of end-to-end vs. by-hop headers: some of the latter ones will be listed in the "Connection" header (did you know that that is its original purpose, and "close" option is but a hack?) but some of the headers are always hop-by-hop and the proxy is expected to filter them even if they're not listed in "Connection" header — but of course the comprehensive list of such by-hop headers doesn't exist. Then there is pipelining. And handling HTTP/1.0 clients (yep, one of the reasons why OP has "IT'S SET TO HTTP/1.1 AND NOTHING ELSE" in his article) who by their nature cannot support replies in "chunked" transfer-encoding. And handling POST bodies in "chunked" transfer-encoding. And handling trailers if you did not cut "Expect: trailers" in the client's request. And there may be comments in "chunked" encoding. And... multiline headers?.. The list goes on and on.

And a decent HTTP-proxy must handle all of that stuff or at least fail gracefully without affecting other clients.