While I understand and agree with what you said, HTTP 2 still runs on top of TCP, which means that when you lose a packet, subsequent packets belonging to other

While I understand and agree with what you said, HTTP 2 still runs on top of TCP, which means that when you lose a packet, subsequent packets belonging to other responses can't be delivered to the application layer, even though there's no reason to delay them. TCP's strict byte order semantics is the problem. If only the HTTP/2 implementation on the receiving side could tell the underlying TCP stack that it wants to opt out of byte order semantics and to deliver data as it's available. That will decrease latency while not requiring any protocol changes on the sending side.