Table of contents
The short answer, at least for me, is that HTTP/2 is underwhelming. For effectively-serial clients like Requests doing web-scraping (or any form of work where the response body is the major component of bandwidth use), HTTP/2 is a bust. The overhead in terms of complexity and network usage is massive, and any gains in efficiency are eliminated if HTTP/1.1 is deployed in any sensible way (allowing gzip and connection reuse). For clients that are more parallel, HTTP/2 has the potential to have some advantages: it limits the number of sockets you need to create, it more efficiently uses TCP connections and it avoids the need for complex connection-pooling systems. However, it does so at the price of tremendous complexity. The computational workload is substantial compared to HTTP/1.1, and ends up providing relatively limited benefits to the client.
Who're the big winners from HTTP/2, then? Two answers: browsers and servers. For servers, they have to handle fewer concurrent connections (so tying up fewer system resources) and can more effectively distribute resources to clients (thanks to server push). For browsers, they can avoid the current limit on the number of concurrent connections per host, while taking advantage of complex flow-control and prioritisation schemes to maximise the efficiency of their bandwidth usage. This is difficult for a generic non-browser client to do in any intelligent way without pushing the burden of those decisions onto their user, and even if it worked, most non-browser clients don't have these specific problems.
