You're still sending packets to the same IP address. QUIC can't obfuscate that itself, all packets have to get routed over IP in the end. The paper relies on very little but that fact.
If one wanted to block VPN connections, they easily could do so by running such detection and then blocking all UDP (QUIC is built on UDP) traffic from the host to the suspected VPN server, too.
What QUIC helps with, in the context of dealing with DPI firewalls, is really just the obfuscation/encryption of as much connection info as possible, such as the SNI/Host in the context of an HTTP server, which normally is sent in plain text even with SSL/TLS (though ESNI efforts are starting to fix this)
So maybe the solution is to double-send all the encrypted packets - once to the VPN endpoint, and once to the original target (but encrypted so it doesn't reach). Or maybe instead of the intended target, to some randomized selection of targets. You wouldn't get responses, but maybe that doesn't matter.
If one wanted to block VPN connections, they easily could do so by running such detection and then blocking all UDP (QUIC is built on UDP) traffic from the host to the suspected VPN server, too.
What QUIC helps with, in the context of dealing with DPI firewalls, is really just the obfuscation/encryption of as much connection info as possible, such as the SNI/Host in the context of an HTTP server, which normally is sent in plain text even with SSL/TLS (though ESNI efforts are starting to fix this)