If I understand the benefits of HTTP/3 correctly, this post also doesn't address one of the major ones: seamless connection handoff during client mobility. Earlier HTTP versions are TCP-based, so if the IP address of a mobile client changes, e.g. because of moving from one cell tower to another or from wifi to/from cell, then the application layer has to notice the lost connection, create a new connection, and move whatever application-level context there is to the new connection. Not all applications do this, and even when they do, it's slow. If my understanding is correct, with HTTP/3 that's no longer necessary — the same HTTP/3 connection can migrate from one IP address to a different one.

Another benefit that isn't measured in this post but has been mentioned elsewhere in the comments here is that the experience on flaky wireless connections (without changing IPs) should be much better. TCP was designed on the premise that packet loss almost never due to physical failure to transmit a packet, and almost always due to routers queues being full (i.e. network congestion). Wireless networks violate this assumption badly: physical-layer issues are the most likely cause of packet loss on a wireless connection. TCP reacts to wifi packet drops by backing off, assuming that some router is overloaded, but the routers are fine — it's just last hop signal that's bad. In those circumstances, the client should just try again instead of throttling the connection to nothing. Since HTTP/3 uses UDP, it can potentially handle dropped packets more appropriately.