Stumbled upon this paper that might explain some of the performance problems with QUIC: [2310.09423] QUIC is not Quick Enough over Fast Internet. Some relevant quotes:
When the bandwidth reaches 1 Gbps, QUIC becomes 45.2% slower than HTTP/2.
QUIC’s Slowness over Fast Internet is due to Receiverside Processing.
The Poor Receiver-side Performance is due to Excessive Data Packets and User-space ACKs.
And one item that might be of special relevance to Storj?
The existing UDP GSO/GRO thus only supports offloading a train of UDP packets with identical lengths specified by the application [37]. This constraint makes directly applying UDP GSO/GRO to QUIC inefficient, due to QUIC’s inherent multiplex nature: QUIC frames belonging to different streams vary in size and are multiplexed after encryption. As a result, if a train of UDP datagrams (containing the encrypted frames) has different packet sizes, existing UDP GSO/GRO cannot offload them
IIUC, Storj does not need the multiplexing nature of QUIC, so maybe it would actually be possible to stick to same-sized datagrams, making it possible to take advantage of UDP GSO/GRO, hence nullifying a big part of the problem.
I recall Storj investigated QUIC not for large downloads, but to reduce latency. Still, customers are unlikely to manually decide per download whether they want lower latency or higher bandwidth, and a single protocol should do both scenarios.
Given the industry interest in making QUIC fast I would assume there will be at some point kernel and hardware-level methods to make it faster than any less popular UDP solution.