Under "QUIC Issues" it mentions "Private QUIC" and offhandedly remarks that there is no way to use QUIC without CA based TLS which is built in. This means that QUIC cannot be used without the continuing approval of a third party incorporated entity. This is a very serious problem when QUIC takes over in user software (made by megacorps) and eventually drops HTTP/1.1 support. It will be the end of the open web and the beginning of a corporate controlled one.

Ignoring this extremely dangerous outcome of a QUIC only world, this write-up is excellent and really clears things up.

Operating a private CA is trivial, there are packages to automate it at every level from simple manual scripting to fully-automated ACME servers such as Boulder[0].

For proprietary software it's idiomatic to use a private CA for securing connections to a central server, to avoid the risk of DNS hijacking or a malicious third-party CA. For open-source software it will, definitionally, allow substituting different server key validation options for users who prefer to run their own servers.

The only real problem QUIC's mandatory TLS causes is that localhost development becomes marginally more difficult, but even as someone who loves running my in-development stuff on localhost it's clear that the security of the internet as a whole is of far greater value.

[0] https://github.com/letsencrypt/boulder