If you just look at the network, leaving out all other factors (source and destination hardware and software limitations, overhead on intermediate devices/routers, ...), there are essentially two factors: bandwidth and round-trip time. For a larger network, the bandwidth of the slowest link in the path is the one relevant - obviously, your throughput cannot ever get higher than that.
If the transmission protocol sends one packet at a time, waits for acknowledgment, and then sends the next, the round-trip time totally dominates the achievable throughput: sending and acknowledging take a full round trip (RTT) and a single packet is transported. The throughput is RTT * packet size, regardless of available bandwidth (unless that is actually lower).
To get around this limitation, many protocols send a specific number of packets before the first acknowledgement is due - most prominently the TCP transport protocol where this is the send window. With the same logic as above, the achievable throughput has now increased to RTT * window size, becoming independent from the physical packet size.
Now, a large, high-bandwidth network may still be limited by the RTT - when the bandwidth-delay product is greater than the possible window size. It may be necessary to increase the window size beyond TCP's standard 64 KiB. This is where the window scale option comes in, increasing the potential window size to appr. 1 GB.
Summing up, if the possible window size is too small to utilize the network's full bandwidth, it's faster to split the data into multiple streams and transport them concurrently.
However, we've previously assumed that the network has appropriate free bandwidth to accommodate our stream. The situation changes when there is contention between the different streams and the network becomes congested. Normally, contention happens between the different streams or connections. So, using multiple connections in parallel may be able to use a larger portion of the congested network: when there are four competitors in addition to your single stream, each connection gets 1/5 of the bandwidth. If you then split your stream into four, each stream gets 1/8 of the bandwidth but your combined streams 4/8 = 1/2 of the bandwidth.
In a nutshell, splitting up a stream into multiple, concurrent ones is faster when a) the window size is insufficient for the available bandwidth or b) when there is congestion on the path and contention is arbitrated by connection
Whether you use FTP or HTTP doesn't matter much from the network perspective - both use TCP as underlying transport layer protocol and should behave very similarly. In practice, that may differ because of differences in the applications and their implementation.