Since the advent of the internet itself, developers writing practically any networking code (particularly when using sockets directly) have had to pick between TCP or UDP for their choice of transport layer protocol.
Neither transport is really optimal for any one particular use case. TCP abstracts over byte streams, but provides reliable delivery via ARQ, flow/congestion control, etc.. On the other hand, UDP abstracts over framed datagrams, but has no QoL features TCP has. What neither protocol supports is per-connection datagram multiplexing or connection handovers.
Developers are then left to either reimplement parts of UDP over TCP, or vice versa, usually picking to implement datagrams over TCP as that is the easier choice.
QUIC is supposed to be a massive improvement to the state of things by implementing the TCP suite of delivery QoL, as well as in-connection streams and support for handovers, all over UDP – in userspace.
Sadly, the spec designers were a bit overzealous when tacking on optimisations: the spec demands a TLS1.3 handshake be part of the transport handshake as well. Although this is great for lowering initial latency times, it chains developers to using TLS for encryption.
TLS is already hostile to use: it requires you to acquire or self-sign certificates, assuming the role of a CA. You also need to deliver your certificate to all devices that should connect with you.
This fact alone strongly binds QUIC to traditionally TLS-transported protocols, such as HTTPS, and leaves developers in want of the feature-set sans TLS frustratingly marooned. If QUIC should ever to hold itself serious, it should ditch the TLS shenanigans and specify TLS and 0-RTT as an extension to a much more generally applicable transport protocol.
If you feel this is a poor technical decision as much as I do, contact me using email or Matrix (see info below), or send an email to the QUIC working group mailing list (<quic (at) ietfa (dot) amsl (dot) com>), and preferrably notify me when you do.