AFAIK, Storj’s QUIC is only implemented in satellite check-ins with the storj node. So, the traffic is nearly zero.
First:
Any discussion of QUIC implemented for the p2p data traffic needs to include a discussion about consumer level ISPs and how many of them throttle UDP traffic to prevent a UDP Flood Attack. Since QUIC encrypts everything, including the headers, there’s no ability to do QoS through third parties. This means that any high traffic WAN data network is going to trigger consumer level ISP’s DDoS sensors… and throttle the UDP packets coming through to an SNO.
To implement QUIC without taking into account the very real threat of UDP throttling by ISPs is simply irresponsible as a project.
Second:
IPFS has a list of providers of content, called a DHT. Earlier versions of Storj had something similar and decided to go with the Satellite model instead in v3. The files in IPFS may be stored anywhere on the network and may be of any size. I’m no longer sure of the file sizes in Storj, but I’m quite sure retrieving files from IPFS will include a sizable sampling of Storj sized files… Whew! that’s a more than a byte 
Third:
I personally, quite literally, experienced my ISP throttling UDP traffic to my WAN accessible IPFS nodes. Disabling QUIC on WAN accessible nodes did not reduce my traffic to those nodes, it simply stopped triggering the ISP sensors yelling at my IP address due to UDP Flooding.
Furthermore, my standard Internet traffic slowed considerably when running WAN accessible IPFS nodes with QUIC enabled.
So…
One could make all sorts of claims about the advantages of QUIC from one “side” or the “other”… but ISPs aren’t going to know that the incoming UDP packet Flood contains QUIC traffic… they are simply going to pull the plug on your connection.