When you're building one single thing that's used by 4.6 billion people, it turns out that percentage optimizations matter!
(I work for a company that built a shitty half-baked homegrown QUIC equivalent because in rural Ethiopia, HTTPS handshakes were so slow that they literally just didn't work. Glad that Google is optimizing our percent-of-a-percent use case!)
Unsound hacks that kind of work "acceptable" in A/B test telemetry and slowly break in real life from inherent design deficiency, are almost always worse than something saying from the start "will not work on bugged os/hardware version, but work really well on standard compliant ones"
The TLS 1.3 hack a Google engineer has forced through IETF is now backfiring for example. They did it to hack around a certain brand of middleboxes, but the hack instead broke few other ones, and embedded http servers. They may well errata it, and go back to normal versioning in 1.4, despite putting it on paper in 1.3 that the hack is here permanently.
How is it "backfiring"? It seems to be working for billions of people. If you've got a non-compliant TLS implementation that broke you get to keep both halves, good luck with that.
I'd be interested to know how you feel TCP and QUIC differ in this regard.
It seems to me that they're both reasonably similar protocols that design for slightly different things and make different tradeoffs (reliable single-stream transfer vs reliable multi-stream transfer, ip and port-based endpoints vs abstract connection ids, etc).
I guess you could see the integration of encryption to be an ugly layering violation, but IIUC the primary driver for that decision is less performance and more to prevent ossification by ensuring as much protocol information as possible is inaccessible to middleware.
I'm less enthused about HTTP/3 - I would've liked to see a simpler, "QUIC-ified" version of HTTP/1.1 done first (ie. basically just normal HTTP except with one request per stream), but I guess it's a hard sell to roll back from HTTP/2's efficiencies, and HTTP/2 itself is unsuitable for QUIC since it duplicates much of its functionality.
I also want to see QUIC used for more protocols, especially those that (like HTTP/2) already had some level of stream multiplexing built in (AMQP comes to mind here).