Libchan is the spiritual child of zerorpc, so it is definitely informed by our experience using zeromq. The main experience was: it's awesome but does too much, too low in the stack, and it's too much of a black box to remove the parts we don't need.
Also, the inability to safely expose it on the public internet was a big problem. I know this has been addressed since then, but we don't want to use a separate protocol stack for that: we want to use the existing HTTP (soon HTTP2) and TLS middleware infrastructure. That's why libchan uses spdy/tls as its main network transport.
Just as forecast by many on HN, HTTP is becoming the network layer.
You must be referring to HTTP2, which is indeed HTTP1+SPDY+TLS in one single protocol. Actually, if SPDY catches on and is used for other uses (I already know muxado  that uses a SPDY-based protocol to multiplex requests/responses between client and servers) so that it lives by itself, it will be funny to see if HTTP2 really embeds it (and therefore duplicating the work).
I think I'd like to move muxado in a direction where it provides the common interface to the various stream multiplexers. That way you could code against a common interface and swap out http2/spdy/muxado/yamux as the implementation to suit your performance needs.
I'd also like to see libchan use this common interface as a layer built on top of this primitive.
Deus, why? Why on Earth would parts of your critical internal infrastructure be exposed to the public Internet?!
Just my 2c based on our own production experience.