Then some sessions get a shitty link and others get a better link. Your bandwidth may go up for a benchmark of a lot of concurrent sessions but your latency will be random and all over the place.

Doing it at the packet level in theory gives you the ability to exploit the aggregate bandwidth for any session but as OP noted you still have all the latency problems and middleboxes getting in the way.

QUIC by the way solves the middlebox problem and you could put individual QUIC streams on separate connections to solve the head of line blocking that can appear but I feel like that’s closer to the TCP session thing where you only benefit the use cases that set up multiple streams. HTTP3 where this does happen may not benefit though because bandwidth tends to not be a problem if your rich enough to afford multiple links in the first place (ie more latency sensitive). This could be useful in places if you build a custom end to end solution for video streaming where you put the time-sensitive parts of the video on the lowest latency link and let the rest of the video buffer across all links. It’s a very niche use case though and not worth the effort I think.