This is about Google's QUIC ("gQUIC") and is based on a version from 2018. It explains in the Related Work section at the end that the IETF QUIC protocol has different properties.
The trade discussed between keeping information for longer to make everything faster versus throwing it away frequently to avert tracking is _everywhere_ already. It's in your HTTP/1.1 web browser's Cookie behaviour, it's in the TLS implementation's resumption feature.
One piece of good news is that in the quest to speed things up putting the public keys into DNS means it's no longer practical to (as is discussed as a potential attack in this paper) give each client different keys so you can identify them that way. Because DNS is cache-based everybody receiving the same version of the cached data will see the same keys. This isn't a problem for good guys, everything works, but if your goal was to track people against their will it's a problem.
The trade discussed between keeping information for longer to make everything faster versus throwing it away frequently to avert tracking is _everywhere_ already. It's in your HTTP/1.1 web browser's Cookie behaviour, it's in the TLS implementation's resumption feature.
One piece of good news is that in the quest to speed things up putting the public keys into DNS means it's no longer practical to (as is discussed as a potential attack in this paper) give each client different keys so you can identify them that way. Because DNS is cache-based everybody receiving the same version of the cached data will see the same keys. This isn't a problem for good guys, everything works, but if your goal was to track people against their will it's a problem.