HTTP/1.1 (RFC2616) specified a limit of two connections per server, which most browsers initially interpreted to mean per-origin, which still lead to quite a lot of unnecessary blocking. I think browsers eventually decided to increase that to 6, but as evidenced by viewing the "Network" tab of the Developer Tools on a lot of modern pages, it is in fact not very uncommon anymore to have a substantially larger number of resources per origin.

While it's true that HTTP/2 can be worse than HTTP/1.1, I don't think it usually is; it's pretty easy to demonstrate just how much better HTTP/2 is over a typical Internet connection. SPDY and HTTP/2 were clearly better and rarely worse, whereas HTTP/3 is almost never worse (maybe when interplay with TCP rate control is poor?) On very unreliable and very high latency connections it can definitely go the other way, but statistically my experience is that a large majority of cases see an improvement on plain-old HTTP/2.

That said, for all of the complexity HTTP/2 adds, it is kind of a nice protocol. I like that all of the "special" parts of the HTTP/1.1 request and response were just turned into header fields. HPACK is a minor pain in the ass, but it is pretty efficient. You get multiple concurrent bidirectional streams per connection and they can each send headers/trailers. There's even the MASQUE protocol, which enables unreliable datagrams with HTTP/3. Put together this makes HTTP/2 and HTTP/3 amazingly versatile protocols that you can really use for all kinds of shit, which makes sense given the legacy of HTTP/1.1.

There are some pitfalls even still. For example, all of this added complexity has made life a bit harder for load balancing and middleboxes. TCP level load balancing or round robin is basically defeated by using HTTP/2 multiplexing, without the client being explicitly cautious of this.