This limit is completely artificial. Let's limit HTTP/2 to maximum 6 multiplexed streams per connection and see how it fares with HTTP1.1 with 6 TCP connections to the server. All of sudden HTTP1.1 wins :)
It’s also a specious argument anyway. The six connection limit isn’t purely artificial, opening and tracking TCP connection state is expensive, and happens entirely in the kernel. There’s a very real cap on how many TCP connections a machine can serve before the kernel starts barfing, and that cap is substantially lower than the number of multiplexed streams you can push over a single TCP connection.
You’re also completely ignoring TCP slow start process, which you can bet your bottom dollar will prevent six TCP streams beating six multiplexed streams over a single TCP stream when measuring latency from first connection.
Oh and while doing that, also feel free to respond to the rest of comment that outlines why opening an unbounded number of TCP connections to a server might be a bad idea.
Besides that, more than half my point is that I like HTTP/2 and HTTP/3 for the featureset, and you can't get that by increasing the max connection limit for HTTP/1.1.
When the limit is reached, all clients would be broken
Looks like a good deal indeed, why do not we do that