You are right. If browsers would expose APIs which would allow to access request and response bodies in a streaming fashion then HTTP/2 (and actually even HTTP/1.1 with chunked encoding!) can be alternatives to websockets.

The remaining difference would be websockets having builtin frame delimiters and a meaning of text and binary frames - whereas with HTTP streams you would need to do that on the appliction level.

Getting Streaming APIs for HTTP was planned to be part of the ReadableStream and WritableStream extensions for fetch - but I have no idea how that effort went since I last looked at it (5 years ago).

Optional reliability and ordering is very important for real-time multiplayer games. Websockets doesn't support this as it uses TCP.

Theoretically maybe, practically definitely not.

HTTP is still very much geared towards request/response semantics, just sometimes serving requests you didn‘t yet know you want to make.

Also, WebTransport seems to be more of an extension of the idea of WebSockets to UDP and other reliability/ordering semantics than an outright replacement.

There’s some discussion around doing HTTP/2 streams (reliable, stream-based) with the fetch API (I am not certain which browsers allow for this), but note that these are only one use of WebTransport - the main thing I’m excited for is doing unreliable datagrams without bringing in an entire WebRTC stack.

Not sure if you missed it or not but QUIC is HTTP3. It has known advantages that are highly valued in domains like games as josephg has mentioned.