Well, it's worse, really. Much of the internet allows only HTTP on port 80 (and some middlebox intercepts and modifies it to "help" you), and SSL on port 443 (generally unmolested).
That is also why we have horrible protocols like WebSockets. (which is used "optionally" with SSL under it; but, realistically, SSL is required if you want it to actually work. Without SSL, a transparent proxy or other middlebox will see your "HTTP" and helpfully rewrite it, destroying the WebSockets connection.)
According to the QUIC docs, part of the reason QUIC only functions encrypted is that they observed intermediate boxes breaking their connections by helpfully rewriting some data when it was sent unencrypted. If you encrypt everything end-to-end, there's little that a middle-box can actually do to you.
These days, end-to-end encryption *with endpoint verification* is the only sure way to say "don't mess with my data".
Unfortunately, the design doc says that QUIC "may" not require certificate validation on port 80 (that is, when used to replace "http"). If that's the case, it'd still be possible to make a middlebox which implements QUIC support, decrypting, mutating, and re-encrypting your traffic. Then, there'd still be the possibility of the internals of QUIC being baked into the network, like HTTP is now.