I think the exact opposite is true in reality, people want to nimbly implement protocols so badly they'd rather shove everything on top of UDP/TCP or even HTTP than deal with waiting around for whole operating systems to age out. From a pure technical design standpoint I agree a lot of things should be done at lower layers but I don't think it's possible for this to happen as quickly as a lot of people are wanting.
Not to mention the second travesty of the layered protocol model in the real world: hardware and configurations have started to grow around it. A lot of networks can't handle QUIC simply because UDP 443 won't go through their firewall yet people are expecting everyone to just jump up and start NATing completely different L4 protocols? Remember IPv6 has been around since the late 90s yet people are still sticking to the same NAT solution.
Became more rambly than I wanted but I'm just a network guy frustrated that we can't keep building up the protocol stack nor can we tear it down.
So pretty much something that will never get implemented in middleware. About the only way for things to get is to tack them on to the HTTP TLS layer and have Google/Firefox for the update to everyone.
I would be very happy if a variant of QUIC became its own OSI layer 4 protocol so we could start re-engineering all higher level protocols to use QUIC rather than UDP or TCP. If we had done that decades ago, not only would a majority of our network security issues have been nonexistent, we would have had extra performance and bandwidth to advance the state of the art. (If you ask "why not just implement it as UDP now and be backwards compatible", it's because operating systems generally don't provide APIs for network protocols higher than layer 4, and we need the protocol to be natively supported by all TCP/IP stacks to grease wider network protocol adoption and reap the benefits for all network applications)