It has unreliable, unordered datagrams, and a huge number of TCP-like streams, all wrapped in the same TLS'd connection.
When I look at QUIC, I see old TCP protocols like IRC and telnet coming back. The difficulty of encryption pushed many applications into HTTPS so they could stay safe, even though HTTPS isn't a perfect fit for every app.
With QUIC saying "You're as safe as possible and you have basically a UDP and TCP portal to the server, have fun", I think we'll see some custom protocols built / rebuilt on QUIC that were lying dormant since the age when encryption was optional.
For instance, multiplayer games could probably just use QUIC as-is. Send the real-time data over the datagrams, and send the chat messages and important game state over the streams. Instead of some custom game communications library, and instead of connecting TCP and UDP to the same server, one QUIC library and one QUIC connection. Now it's within the reach of a solo indie developer who wants to focus on their game-specific netcode, and not on re-inventing networking ideas.
https://quicwg.org/datagram/draft-ietf-quic-datagram.html
They're working on it, I guess.
if something doesn't start loading in 5 seconds and you are still giving it time without jumping up and down, tcp gave you stockholm syndrome.
I'm not familiar with quic so I don't know how to feel about it, but we are in dire need of an alternative that doesn't require reimplementing the good parts of tcp over udp like every game and communication apps in the world do.