TCP has a few ugly problems that enhance each other. First you need to wait till all the handshaking stuff is done and then you can't even transmit with full speed.
If you use UDP, you have to implement much of the TCP stuff yourself. But you can use the experience with web connections to implement it and leave out things that weren't needed.
> [...] and then you can't even transmit with full speed.
This is nothing specific to TCP. "Full speed" is a fundamentally unknowable quantity in advance in the general case. It varies with time and endpoints. If you try to start a connection transmitting at the full speed of your first-hop link (the only one you have any chance of knowing the bandwidth of), you just put the congestion control a hop or more away from the box that has the information necessary to do it right.
QUIC can have an advantage in re-using a connection in situations where multiple sequential TCP connections might have been made. Probing for link bandwidth fewer times is not the same as not having to probe for link bandwidth. And HTTP/2 has already addressed the most common case of this without abandoning TCP.
If you use UDP, you have to implement much of the TCP stuff yourself. But you can use the experience with web connections to implement it and leave out things that weren't needed.