Even if quic would bring along an unreliable stream option: The browsers Api still only expose http semantics via xhr and fetch. So those would need to get extended too.
Sure there are possibilities, but they all require additional standardization (which takes time and effort).
WebRTC has unreliable data channels, but they are based on sctp/dtls/udp. Making them work over quic streams might be possible, but also requires a new standardization effort.
If someone does it I would actually prefer an API outside of webrtc, since that one carries a lot of complexity for signaling and requires again a few extra protocols (ice, stun, turn, etc). An unreliable/unordered client to server protocol and api could potentially be much simpler.
https://w3c.github.io/webrtc-quic/ is "outside" of webrtc in the sense that it doesn't use PeerConnection and doesn't require signaling. But it currently doesn't require some form of ICE (not stun or turn, but ICE lite on a server). But we're considering adding support for an ICE-less version, and I've already started a pull request to add that.
There is a WebRTC over QUIC experiment, the standard document can be found here: https://w3c.github.io/webrtc-quic/
It is currently not a work item of the W3C WebRTC WG, but we hear about it every time we meet.
The current focus right now is to deliver WebRTC 1.0, when this is done, we may reconsider it.
At TPAC last week the WebRTC WG decided to adopt the spec, although it needs to be verified on the mailing list, as there were some members present not in favor of adopting it.
(I'm an editor of the document and am in favor of it).
