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