Middleboxes can equally well insist upon tampering with other data they can't interpret in QUIC, and that too just causes the packets to be discarded. To what end? Middleboxes aren't actively malevolent they're just built by idiots.
Our experience has been that middlebox vendors _ossify_ things. They see a field that's defined "Zero: Reserved for future use" and they say "Aha, that's supposed to be zero" and so now that "future use" can never happen.
For example the Certificate in TLS 1.2 and earlier isn't intended to be useful to anyone except the TLS Client. But middleboxes interpret it anyway, they insist it should be an X.509 certificate, possibly from a known CA - and so it's impossible to add a "Gzip'd Certificate" feature to TLS 1.2 even though if you look at the protocol description it's easy to see how, if you actually tried you would find middleboxes throw a fit since this isn't X.509 and now your software can't be deployed.
But in TLS 1.3 compressed certificates are a thing, because TLS 1.3 encrypts almost everything and that includes Certificate. A client can say "I grok Compressed Certificates" and the server goes "Here's a Compressed Certificate" and nobody else is any the wiser. A middlebox doesn't know about it and so it can't meddle.
My specific worry is that some "firewalls" will try to use the little that's still visible (the spin bit, packet sizes, packet timing, etc) to try to guess whether the connection comes from a "legitimate" source like a common web browser, and discard the packets otherwise. "You flipped the bit when you should have flopped it, so you're a malware and I'm going to blackhole your whole IP address for the rest of the day", things like that.
This is a significant (and for the "IT security" industry expensive) change compared to previous versions but it was done with this in mind. The methods often employed to avoid doing proxying don't actually deliver security though they did ossify the protocol but they are cheaper. Too bad.
Let's take my compression example again. Your "firewall" won't tell you it understands compressed certs since it has no idea what they are, and it won't request them from the server, no ossification. New features don't work for you inside your "firewall" making the Internet worse for you, but for everybody else improvements continue.
The same for the spin bit. Corp A enforces a completely broken spin bit for "security", it suffers mysterious and hard to diagnose network faults but the rest of the Internet isn't affected and life continues as normal.
All they can do is corrupt or block the packet, which looks to the end user like high packet loss on random connections... earning that router type a reputation for being very slow and pushing it out of he market.
I hope that's all that happens. My worry is that middleboxes will start to depend on it, and any implementation which doesn't spin it "correctly" (where "correctly" is defined by the middlebox vendor, not the standard) will be blocked.