Back then TCP was the best mainstream choice. Using UDP would have looked good due to its message orientation. But its limited message size, lack of re-ordering and congestion control would have disqualified it almost directly. TCP then looks better, since it has reliability, re-ordering and rate control. You only need to change the streaming functionality for senfing messages. This they did by using one TCP connection per message. What they missed, however, was that connections are expensive in TCP. There are a lot of handshakes and TCP probes a lot before opening the throttle, something you notice when downloading a big file. Throwing away connections like that is a waste. Ideally, you would want one connection per server and reuse it for multiple requests. This was done in HTTP 2.0, where connection:keep-alive was introduced. But TCP still has significant overhead and a slow rate control mechanism. It also does not allow multiple concurrent requests in the same connection. These problems are addressed by SCTP, which is really a great fit for HTTP and awesome in general. It is also message oriented. SPDY is another similar alternative, which is less general than SCTP.
But the point I was trying to make is that TCP was intentionally crippled by HTTP to acheive REST. Then people hack the restrictions of TCP and declare a new invention.