Here is a Google Chrome discussion about it from 2018: https://groups.google.com/a/chromium.org/g/proto-quic/c/pAQz...

Here is a quick overview (undated) from Google about it: https://peering.google.com/#/learn-more/quic

The phrase in that last one is: "multiplexing without head of line blocking". If you search for that phrase you will get a bunch of results. The browser is an extremely limited interface with regards to transmission, so the solution in the browser is always open more sockets. However, on the server, the advantages are huge.

You have to understand that multicast is OSI layers 2, 3, and 4. Its layer 2 because it uses a NIC as a local identifier for management apart from other multicast sockets available, UDP and TCP are layer 4 protocols, and it also takes on some layer 3 capabilities for congestion management. This is where the CPU advantage comes in, because you are offloading some of the traffic processing elsewhere in the stack and to network devices, like switches/routers.

Yes, Google has said that part of the motivation was reducing CPU load but I cannot remember where I saw that.