Thanks for reporting this, I wasn't aware of this issue on Juniper routers. It looks like the end result would be low bandwidth connections experience low to no packet loss, and higher bandwidth connections like Maps and YouTube experience much higher loss?
Chrome has mechanisms to fallback to TCP if UDP is blocked or blackholed, but not if it's severely rate-limited. We attempted to create some heuristics earlier in the project, but no approach worked well. For example, there are networks with packet policers like you described installed for all traffic, and in those cases, falling back to TCP turns out to be the wrong choice from a user-experience perspective.
Now that QUIC is an IETF working group(
https://datatracker.ietf.org/wg/quic/about/) close to adoption of a first draft, I'd like to work on preventing differential treatment between QUIC and TCP, since detecting it correctly is extremely difficult.
Previously, I was under the belief that the type of settings you encountered are now rare, or when they are enabled, UDP 443 is also blocked? Do you know if this was the default on the Juniper?
Thanks, Ian