On one hand, you have tcp, which already allows you to multiplex multiple streams, every bit of software understands it, and your back office web application servers fully support it. Yes, it has limitations (slow start applying to individual streams instead of all the streams between two computers seems to be the primary one), but instead of trying to fix it (which admittedly would take a lot of work and would be a slow process), you take a single tcp stream and implement multiplexing all over again, now you have to work support into all your applications from top to bottom. Not surprisingly, this also takes a lot of work and is slow process.
TCP is a transport layer and we're not talking about replacing TCP - not going to happen, and no reason to do that. 0MQ, SPDY, etc, run at application layer, and TCP flow control, window sizing, etc, work in tandem with the application layer controls.
Why do you think multiplexing multiple independent streams at the application layer instead of the transport layer is a good thing? Now that people are using it they find they have to re-implement the other things the other things the transport layer does (like demuxing the stream and sending each part to the correct backend service)
Yes, replacing or modifying TCP would be a long, slow process, but so is re-implementing all its functionality at the application layer. Google introduced SPDY over two years ago (Nov 11, 2009), and as the article points out, there is still a whole lot of work that needs to be done before it lives up to its promise.
"To minimize deployment complexity. SPDY uses TCP as the underlying transport layer, so requires no changes to existing networking infrastructure."http://dev.chromium.org/spdy/spdy-whitepaper
