The issue you linked to is an excellent example of why everyone and their dog is becoming a CNA these days. It's the only way to keep CVE spam at bay. The system has been broken by the gamification of CVEs and is in desperate need of reform.
Anything that involves high latency and/or packet loss. And in general: testing servers.
The question is also a bit odd, to be honest. There's no need to look for a beneficial use case to add support for the next iteration of the HTTP protocol.
There is quic-go[1] but i don't think that it's sufficiently optimized[2-4] to be used for this kind of workload. caddy will use it to provide HTTP/3 by default[5] in the upcoming 2.6.0 release.
I have also been struggling lately with prepared statements and obscure query planning decisions. The developers of the mssql JDBC driver seem to be determined to force the use of prepexec in their driver, which causes high execution times for typical ORM-generated queries:
Satellite networks are not a good example. Regular HTTP/1.1, paired with a PEP, outperforms HTTP/3 by an order of magnitude.