A long-term connection is established between peers, as for TCP, but this can use multiple redundant paths rather than a single path. Within that connection, multiple independent streams with reliable transmission can exist - which relates to the RPC problem raised in the article, and to situations such as requesting parts of a web page in parallel.
NAT might not be a huge problem, as the protocol does have source and destination ports. One could also envision a proxy on a client device to translate HTTP/TCP to HTTP/SCTP for browsers not yet using SCTP directly. However home routers would probably be an insurmountable obstacle to widespread adoption, and neither Windows nor MacOS currently support SCTP.
If anything, the fact that a billion crappy unadjustable unmoving assumptions arent built into QUIC seems like an obvious win. TCP itself has a bunch of modern re-spins on what traffic control might possibly be better (bbr2 being a recent notable), yet there's so many legacy systems which already impeded progress & growth & basic modernization...
Conversely with QUIC, Broken shitty networking gear is about to get found out & replaced, when the modern QUIC internet takes over the vast majority of traffic & is just better. The "smart" middleboxes have long been more problems than aids, & their ancient cruft auto-magic is more hinderances in most places than than help.
Dropping & throttling UDP better will be a fine middleground, one where middleboxes have less control, but the end to end rather than hop to hop to hop protocol will adapt better.
However, I don't think it is fair to suggest that QUIC will do anything to fix that infrastructure. QUIC, for better and worse, intentionally kicks the can further down the road by hopping around on top of UDP infrastructure. Maybe some QUIC successor will have the guts to move things to a proper top-level protocol, but QUIC itself isn't yet that step.
The "narrow waist" concept was originally that the only protocol that the internet required every network to speak natively or directly was IP. TCP and UDP were intended to be two protocols among many at the next layer up, but through various factors and accidents things got ossified to just those two protocols at that layer and even that so much so that increasingly in the last few decades TCP/IP is seen as the "real internet" (the "waist" expanded).
From that perspective QUIC looks like a hack: it's built at the next layer up (on top of UDP rather than a true peer among UDP and TCP) because building at the right layer level is "no longer allowed" (thanks to decades of firewalls, middleboxes, routers with bad assumptions baked in, etc).
Those things that ossified TCP, though, are also many of the reasons that QUIC can't compete with TCP and that TCP is inherently special on the modern internet as one of only two "approved" protocols and something of a "last man standing" even among them. As an example, pointed to in that RFC list, QUIC has to define its own congestion control, and it's something of an application-level service. TCP has decades of congestion control tech in the wild, some of it baked incredibly low level into routers, so much so that a lot of it is just "automatic" and "magic". Applications don't need to do any work to opt-in to it. It's sad that that work is hard-coded specifically to TCP and only TCP and cannot be easily applied to new network protocols, but that's just the reality of the modern internet.