So like others have pointed out, this is not aiming to replace UDP any more than HTTP is aiming to replace TCP. So it's more like a feature rich TCP replacement, a transport protocol that happens to sit on top of UDP (which is what you have to do unless you want to write a OS driver).
As for impact, depends entirely what applications they plan to deploy it on. WebSockets, peer-to-peer WebRTC and media streaming could benefit from real-time friendly properties (fixing head-of-line blocking and enabling selectively unreliable packets). Hard to see anything significant for traditional web content delivery.
There are many things that you might want from a post-TCP transport protocol. Look at some of the SCTP features for a taste. It has stream multiplexing over the single connection, multipath and dynamic address changes, datagram mode, per-message reliable/unreliable option, to name a few.
SCTP seems to have bombed partly because they were "doing it right", ie getting their own IP protocol number and trying to get it deployed inside OS IP stacks instead of of sitting at application level on top of UDP.
The FEC feature in QUIC sounds a little unorthodox unless it's for multicasting or some control plane function, since at this protocol layer it's considered prudent to be sensitive to congestion when coping with packet loss...
Low uptake as routers will not have built-in support, and admins will be slow to enable it when and if it becomes available (unless its tunneled over another protocol).
IPV6 vs IPV4 question is orthogonal to those addressed by the QUIC protocol. IP layer is for addressing nodes on the internet and routing packets to them in a stateless manner (more or less... I'm not counting routing table caches and such as "state"). TCP (and this QUIC protocol) are built on top of the IP layer to provide reliable end-to-end data transfers in some sort of session based mechanism.
I was thinking primarily of the security aspects, which is one of the few things called out. I'm all for secure and discrete transfers of data between endpoints, since TCP programming APIs often require maintaining process state for each connection and can impact service scaling.
If this is really more or a session layer protocol on top of UDP instead of its own transport protocol, then all the more power to them. It will be more of a programming model than a network configuration quagmire, and I'm sure that eventually intelligent optimizations can be performed via packet inspection if the protocol state details are not encapsulated deep within the security (i.e., trust/privacy) bubble of the protocol.
Is this just going to mean faster and more secure data transfer, or are there wider implications?