You should read the design document and specicifaction rationale, it has more details than a blog post. Considering on the first page, in bold font it describes QUIC as "Multiplexed Stream Transport over UDP" it should only be compared to TCP+TLS in operation - but it helps to solve the multiplexing problem for anything that decides to take advantage of it directly. The majority of applications using TCP+TLS as a transport today have the same problem and open many sockets during operation.
Agreed SPDY and HTTP/2 have multiplexing built in - but so does QUIC.
"This is a working document, for group discussion and editing, which we expect to evolve into a somewhat fleshed out design document. The expectation is that we will flesh out a design for a tunneling protocol, running atop UDP, which can multiplex a large number of streams between two endpoints (a client, which initiates the overall connection, and a server). Each stream may, for example, be nearly equivalent to an independent TCP connection."
Edit:
And this...
"Pairs of IP addresses and sockets are finite resources. Today, too many distinct connections are routinely made between clients and servers, utilizing a multitude of sockets, and often carrying redundant information. A multiplexed transport has the potential for unifying the traffic and reducing the port utilization count. A multiplexed transport can unify reporting and responses to channel characteristics (packet loss, etc.), and also allow higher level application protocols (such as SPDY) to reduce or compress redundant data transmissions (such as headers). In the presence of layer-3 load-balancers, a multiplexed transport has the potential to allow the different data flows, coming and going to a client, to be served on a single server."
