I think that most of the objection is that with HTTP/1.1 you can type "telnet example.com 80" and type out an HTTP request and read the reply. I see similar arguments about why JSON is better than protocol buffers. All the necessary keys are on your keyboard. At the end of the day, I just write a tool to do these binary-exchanges for me. If I need to send a protocol buffer message to some server, I just write a program to do that. It's 3 lines of code. If I do it a lot, I check it in and write documentation. There are plenty of reusable generic mechanisms that already exist, too. curl for all of your HTTP request needs. OpenAPI to make an app that talks to your custom API.

People tend to draw the line exactly at their current level of understanding. A few years ago, people would say "SSL is only for corporations", but with Let's Encrypt, you don't see that come up anymore. They're comfortable not having keys on their keyboard that can do the TLS handshake, because they now understand the server-side and client-side tooling, and the obscurity of a binary protocol they can't type out is no longer an impediment to productivity. Soon, they'll be comfortable with HTTP/3 as well.

You can't use QUIC without CA based TLS. There do not exist CAs run by human persons that have root certs in popular browers. They are all run by incorporated entities. It is bad that a human person trying to connect to another human person cannot do so without the continuing approval of a third party corporate person.

For companies and institutions this requirement makes perfect sense. It's a great protocol for doing business. But for human people it introduces yet another layer of centralizing complexity for legal and social pressures to be applied and abuses to be enforced. It also makes setting up a webserver even more complex forcing more centralization in hosting. And not that anyone cares, but you can't legally use QUIC over amateur radio like you can HTTP or even HTTPS with a null cypher self signed cert.