"the authors point out that their work shows it has "inherent advantages over TCP in terms of its latency, versatility, and application-layer simplicity".
That's pretty much the exact targets of QUICs performance advantages. In most network conditions with similarly configured congestion control algorithms TCP and QUIC will be capable of the same throughput - which is pretty obvious as it is the congestion control algorithms that manage the rate that packets flow so the only differences there are protocol overheads.
Latency is a really important factor in web browsing. The browser has to download a page, parse it, work out the links and then request those objects. Typically these objects are small and it is the round trip times and handshaking that starts to dominate. If particularly if you are connecting to other HTTPS servers the negotiation phase can be expensive. QUIC is designed to remove those round trips during the handshake and start delivering data quicker. Other features like parallel streams and push support also help with latency reduction. Pushing means the server can deliver the main webpage and then immediately start delivering the associated assets without waiting for the client to request them. Streams means the client can ask for a list of files and the server can send them interleaved. If file A takes 3 seconds of processing to be created it can just get on with sending file B and C. In HTTP you can either pipeline which just means you queue up the requests but they will still be delivered sequentially; or create multiple TCP connections which is expensive for both the server and client and due to TCP slow start it takes time before each connection can get maximum throughput.
Another beneficial feature of QUIC is the ability to cancel file transfers. In HTTP this isn't possible, if you want to abort you have to close the connection and then re-establish a new one. TCP slow start then kicks in where it takes time for the network stacks to calculate the optimal window size, initially the transmission sizes are limited.
To use it to its best this does in particular mean you need cleverer servers that implement and exploit all the relevant features. The conclusion "QUIC does not automatically lead to improvements in network or application performance for many use cases" is not really surprising.
The second issue with this research is that TCP has been the dominant protocol for decades so a lot of effort has gone into optimizing it. Even commodity network cards have all sorts of optimizations in them to get the best out of TCP and offload work from the CPU (calculating checksums, packet defragmentation, etc), linux has support serving http(s) directly from the kernel, and TLS offloading or even serving directly from the NIC is possible on more expensive chipsets. Historically UDP has been a second class citizen relegated to taking the slowpath rather than optimized TCP pipelines.
Effectively the comparison is between a highly optimized internal combustion engine with an electric milk float. In heavy traffic the milk float and petrol car are going to get the same performance (the congestion control techniques of the roads is the limiting factor). Over the last decade electric cars have got better rapidly, and whilst E1 cars still don't quite match F1 in time they surely will. The same can be said of QUIC, as QUIC implementations and hardware are optimized performance will increase significantly.
Finally QUIC has the advantage that much less of the code is in kernel space, this means servers can theoretically be optimized much easier for their use case - using different congestion control algorithms or other logic based upon if they are regularly serving lots of small files, or few large files. Custom TCP stacks with this flexibility is a much harder proposition.