HTTP is the universal protocol because the mental model of "verb-metadata-payload" fits almost everything you can imagine, and the socket handshake/framing parts are obvious and very performant. This is why HTTP is used everywhere from pushing stock quotes to industrial automation.
HTTP 2 and 3 aren't universal protocols, they solve a very specific problem of serving static content to browsers for Google-scale websites.
In effect, HTTP 2 and 3 are exactly the kind of niche one-problem protocol that HTTP was supposed to replace.
This is a pretty facile analysis. HTTP2 is faster, more flexible, and more reliable than HTTP1. HTTP2 also eliminates the need for several silly performance hacks in HTTP1. The differences might not matter for your static site, but they matter a lot for larger applications, and, more importantly, they open the door for using HTTP2 in situations where today people would be building their own clunky ad-hoc protocols; that's the opposite of the phenomenon you describe with respect to the two protocols.
HTTP3, more the same! The performance wins of HTTP3 won't matter at all for most typical web applications. But typical web applications aren't the point of HTTP3.
My concerns have nothing to do with HTML/CSS/JS, but rather the suitability of HTTP as a transport for arbitrary client server protocols --- the subject of this thread. For general transports, multiplexing alone is an obvious win over HTTP.
HTTP is the universal protocol because the mental model of "verb-metadata-payload" fits almost everything you can imagine, and the socket handshake/framing parts are obvious and very performant. This is why HTTP is used everywhere from pushing stock quotes to industrial automation.
HTTP 2 and 3 aren't universal protocols, they solve a very specific problem of serving static content to browsers for Google-scale websites.
In effect, HTTP 2 and 3 are exactly the kind of niche one-problem protocol that HTTP was supposed to replace.