Actually, the mistake in IP was in not encrypting the next layer, so that networks can block transport protocol innovation by filtering anything other than TCP and UDP. This is the mistake that quic has fixed.
This now means that innovations based on Quic can occur
Also, the overhead of a UDP packet is 8 bytes total, in 4 16-bit fields:
- source port
- dest port
- length
- checksum
So, we can save a max of 8 bytes per packet - how many of these can we practically save? The initial connection requires source and dest ports, but also sets up other connection IDs so theoretically you could save them on subsequent packets (but that's pure speculation, with zero due diligence on my part). It would require operational changes and would make any NATs tricky (so practically only for IPv6) Length and checksum maybe you can save - QUIC has multiple frames per UDP datagram so there must be another length field there (anyway, IETF is busily inventing a UDP options format on the basis that the UDP length field is redundant to packet length, so can be used to point at an options trailer). QUIC has integrity protection but it doesn't seem to apply to all packet types - however I guess a checksum could be retained for those that don't only.
So in sum maybe you could save up to 8 bytes per packet, but it would still be a lot of work to do so (removing port numbers especially)