Second system syndrome?
tl;dr I see no fundamental advantage to QUIC that can't be achieved with existing protocols (possibly with some comparatively minor optimisations in the kernel or API layers).
QUIC is a hugely complicated protocol. The amount of code needed to implement it is enormous (look at the Chrome open source repo for an idea of the client-side cost). That suggests the benefits should be very apparent and significant to justify the cost and risk. However..
1. The multiplexing benefit mostly replaces multiple sockets implemented in the kernel with multiple "streams" implemented in user-space.
But there is no fundamental reason why the cost/state of a TCP socket is higher than the cost/state of QUIC stream - after all, they more or less do the same thing. In the old days sockets were expensive but that is no longer true as kernels improve and memory becomes cheap.
2. There are very few if any high-performance friendly APIs for QUIC such as select(), epoll(), kqueue() or libev/libevent at a higher layer. This significantly hinders adoption in existing applications.
3. In some ways QUIC is anti-thetical to high-performance programming and multi-core CPUs.
You essentially need to funnel all of a QUIC connection's traffic thru a dispatching thread to farm out stream traffic. This implies user-space driven context-switching costs. No such implementation model is forced on you when using separate sockets.
As a simple example, adapting Apache's httpd server to QUIC would incur significant performance costs and application complexity.
5. In many regards QUIC is no different from SCTP (RFC4960), so why not use or incrementally improve SCTP? Google have invested enormously in QUIC. If that effort had been directed at an SCTP++ we would have seen a fantastic improvement by now that would be readily available to a much larger development community.
Admittedly a number of these criticisms could be addressed by moving QUIC into the kernel, but that seems to go against the philosophy of the QUIC proponents. But even then are you merely re-implementing a variant of SCTP?
For my money, enhance SCTP and present SCTP streams as sockets to applications and you have a ready-to-go QUIC alternative at about 1/100th the cost.