Yes - and I'd say WebSockets have been sucking the juice out of the DataCenter if your clients are mostly idling!
I'm not disagreeing with you here. Our point was that HTTP 2's features start doing amazing things after the first request, now that they have a connection going. Do read that we are excited about what it brings - just not for the very first request itself. And honestly, if they changed that, we'd be a happier lot.
Even that first request benefits from things like header compression and the more efficient encoding. The big win, however, if you are making an API client is that you can connect and immediately send all of our requests without needing to issue them sequentially. If your API design in the past has needed to prepare combined responses to reduce latency that can a pretty big win.
https://http2.github.io/faq/#can-i-implement-http2-without-i...
This bit is also mostly wrong:
“However, the problems with HTTP2 are not because of HTTP2 itself, but because of the heavier costs of provisioning and maintaining healthy infrastructure that can afford to keep stateful long TCP/IP sessions by themselves.”
That's already been the case with HTTP 1 keep-alives and even more so with web sockets and unlike in the late 90s it's just not an issue for the vast majority of services.
That said, HTTP/2 also has no requirement that you keep a connection open after you're done with the request – the specification clearly states that either end can cleanly close the connection at any point. A browser might choose to implement something similar to the traditional keep-alive timer but there's no reason why you can't make a single request or close the connection immediately after a fetching a single round of resources. The only difference is that this process is both faster and more reliable than it was with HTTP 1 keep-alives & pipelining.