UDP pretty much just tacks a source/destination port pair onto every IP datagram, so its primary function is to allow multiple independent UDP peers to coexist on the same IP host. (That is, UDP just multiplexes an IP link.) UDP as a protocol doesn't add any additional network guarantees or services on top of IP.

QUIC is still "their own protocol", just implemented as another protocol nested inside a UDP envelope, the same way that HTTP is another protocol typically nested inside a TCP connection. It makes some sense that they'd piggyback on UDP, since (1) it doesn't require an additional IP protocol header code to be assigned by IANA, (2) QUIC definitely wants to coexist with other services on any given node, and (3) it allows whatever middleware analyses that exist for UDP to apply naturally to QUIC applications.

(Regarding (3) specifically, I imagine NAT in particular requires cooperation from residential gateways, including awareness of both the IP and the TCP/UDP port. Allowing a well-known outer UDP header to surface port information, instead of re-implementing ports somewhere in the QUIC header, means all existing NAT implementations should work unchanged for QUIC.)

It's effectively impossible to use anything other than TCP or UDP these days.

Some people here will argue that it actually really is, and that everybody experiencing issues is just on a really weird connection or using broken hardware, but those weird connections and bad hardware make up the overwhelming majority of Internet connections these days.

Yeah, so... You can do it. But only for some values of you. In a NAT world, the NAT needs to understand the protocol so that it can adjust the core multiplexing in order to adjust addresses. A best effort NAT could let one internal IP at a time connect to each external IP on an unknown protocol, but that wouldn't work for QUIC: Google expects multiple clients behind a NAT to connect to its service IPs. It can often works for IP tunneling protocols where at most one connection to an external IP isn't super restrictive. But even then, many NATs won't pass unknown IP protocols at all.

Most firewalls will drop unknown IP protocols. Many will drop a lot of TCP; some drop almost all UDP. This is why so much stuff runs over tcp ports 80 and 443; it's almost always open. QUIC/HTTP/3 encourages opening of udp/443, so it's a good port to run unrelated things over too.

Also, given that SCTP had similar goals to QUIC and never got much deployment or support in OSes and NATs and firewalls and etc. It's a clear win to just use UDP and get something that will just work on a large portion of networks.

When it comes to QUIC, QUIC works best with unstable end-user internet (designed for http3 for the mobile age). Most end-user internet access is behind various layers of CGNAT. The way that NAT works is by using your port numbers to increase the address space. If you have 2^32 IPv4 addresses, you have 2^48 IPv4 address+port pairs. All these NAT middleboxes speak TCP and UDP only.

Additionally, firewalls are also designed to filter out any weird packets. If the packet doesn't look like you wanted to receive it, it's dropped. It usually does this by tracking open ports just like NAT, therefore many firewalls also don't trust custom protocols.

Using UDP means QUIC support is as "easy" as adding it to the browser and server software. To add it as a separate protocol would have involved all OS's needing to add support for it into their networking stacks and that would have taken ages and involved more politics. The main reason QUIC was created was so that Google could more effectively push ads and add tracking, remember. The incentives were not there for others to implement it.