Google is not Requesting For Comments at all. It is imposing its things. Despite the fancy number, this is not an RFC at all, in the ancient sense of the acronym, nor it has the same design principles of simplicity and orthogonality.
As far as orthogonality goes, it seems to be pretty orthogonal to different kind of uses, I'm not sure why you're saying it's not.
On simplicity it's definitely not simple, but given the problems it is trying to solve it's probably as simple as it could be.
There is no requirement for people to implement this protocol and it won't be appropriate to every use case that exists today. TCP, UDP, HTTP/1.1, and HTTP/2 are not going away - all continue to undergo standardisation, research, and new implementations.
(Disclosure: I'm not a Google employee, but I have participated in the QUIC and httpbis working groups)
Or at a philosophical level, gQUIC is an HTTP replacement, it doesn't do anything else except a better HTTP, so it doesn't need to care about any features you might want for, say, SMTP or IMAP or IRC unless it wanted them for HTTP. gQUIC knows about HTTP headers. But the IETF QUIC is a replacement for TCP not HTTP. That's why there's an entire HTTP/3 standard in this bundle of RFCs which sits on top of QUIC as its first "customer".
It's coming back now; I definitely remember reading some early drafts and thinking "boy it's sad this is just HTTP 3.0-rc1". I always liked SCTP; I'm glad IETF-QUIC has moved back towards being (sort of) SCTP-over-UDP as well as a better HTTP.
On the encryption front I don't remember reading about a non-TLS version (I probably missed it). I'm kinda sad that got dropped. TLS is just crazy complicated in ways that are unnecessary for non-web things like ssh and wireguard.... X.509 and the whole certificate authority trainwreck.
I really hope we get a "QUIC with non-TLS encryption" at some point in the future.
An example of that first: Does your phone try to connect to SomeBrand WiFi networks? How does it know if this is a "real" SomeBrand WiFi network? It doesn't. In some scenarios this means you leak valid credentials for the "real" SomeBrand to bad guys. In most cases you at least leak identity information. That's not great news. If the WiFi network was named example.com the WiFi AP could of course present a certificate for example.com, leveraging the Web PKI.
Now, there are people who want to do QUIC without TLS, mostly what they want to do is NOISE. Like this: https://www.cryptologie.net/article/467/quic-noise-nquic/ But again, I think something like SSH is the exception and the Web PKI is more applicable to most uses for QUIC.
But it appears that the removal is not permanent, and that it was removed mainly because it is something that can be added later ("QUIC 1.1") in a backward-compatible way.
The other really interesting part was the "spin bit". It's intuitively clear how it could be used by ISPs to monitor the latency impact of their decisions. Unfortunately the cynic in me knows somebody will find a way to use it for fingerprinting. Room 641A really ruined the ISP's credibility in a permanent way.