Yes, it being muxed into a single TCP stream was marketed as an advantage originally, as for almost all mainstream OSes, and network hardware, handling fever TCP connections faster is easier than more more slower connections.
Even if a packet loss was to occur, it would still have a net benefit over pounding a CDN with countless individual requests.
Problem with multiple TCP connections is slow TCP startup. When TCP connections are established and "warmed up", multiple TCP connections are almost always work faster and more reliable.
That was exploited back in the day by download managers which opened multiple connections to the save resource and managed to significantly increase download speed.
> That was exploited back in the day by download managers which opened multiple connections to the save resource and managed to significantly increase download speed.
Even back then, that wasn't anything to do with multiple TCP connections being fundamentally faster somehow. The speed increase achieved by download managers comes down to:
1. DNS resolution round-robin-ing you to different CDN nodes, such that you're actually making requests to different hardware that each has its own NIC to separately saturate; where if the each server NIC can do 1Mbps, and your link can do 2Mbps, then you need two parallel chunk downloads from separate servers to saturate your link. (This is the same fundamental reason downloading e.g. an OS installer through a torrent is usually faster than downloading it through HTTP from the OS maker's CDN.)
2. Intentional per-connection download-rate throttling applied by many servers (especially those of "download sites" like CNet, which "back in the day" were one of the main places people would experience large downloads); where making multiple concurrent HTTP range-requests to the server at once was a way to bypass the server's throttling. You don't see this advantage any more, as these days the servers of "download sites" have enough smarts to dynamically aggregate downlink quota between nodes in a table keyed by peer IP, such that N concurrent downloads from the same site are always each throttled to 1/Nth the rate.
Multiple TCP connections might increase speed even to single source because of the following reasons:
1. TCP connection increases speed gradually over time until it hit some bandwidth limit. So if you open 10 connections, you'll hit that limit faster.
2. Rare packet drop will drop connection speed and it'll take some time to restore that speed on a given connection. With multiple simultaneous connections and rare drops only one or two connections will experience that speed drop, while other connections might even compensate that with increased speed.
So if your connection is flawless, it does not make sense. Otherwise it might make sense.
Even if a packet loss was to occur, it would still have a net benefit over pounding a CDN with countless individual requests.