But the implementation of TCP acknowledgement is implemented as a single stream with head of line blocking. One lost packet effectively pauses everything until the retransmission happens. (Well ok its a bit more complicated than that but the simplification is close enough to reality).
QUIC builds acknowledgement on top of UDP (in the same way TCP builds it on top of ip). This means it has greater flexibility to evolve more complex acknowledgement protocols - such as allowing traffic for other substreams to continue and only holding up the subs-stream with the lost packet, or deciding its a real time video stream and its better just to continue and let the error handling in the video decoder handle some missing data.
The designers of QUIC basically had 3 choices:
1. Build it on top of TCP just like HTTP and HTTP2. This meant all the problems and limitations of TCP, especially related to flow control.
2. Create a new protocol on top of IP alongside TCP/IP and UDP/IP (QIC/IP), Architecturally this would have been the cleanest approach, but would require all networking equipment and stacks to be updated to support it, we have seen how that has worked for IPv6
3. Layer it on top of UDP so that it can be used on the existing internet infrastructure, but create a new connection orientated protocol - QIC/UDP/IP
Option 3 was definitely the wisest decision, but it does cause confusion as people assume that means it 'is' UDP with its limitations, rather than the reality of its building something new on top of UDP for convenience.