* With ZeroMQ you can have Pub/Sub between two nodes without an intermediate server and thus obtain lower latency.
* ZeroMQ will allow you to scale up to really large numbers because of the way it can distribute it messages or the way it uses multicast. With Redis you are always limited to the maximum amount of connections on a single machine.
* ZeroMQ uses message batching techniques and is thoroughly optimized for throughput performance this is a completely different design goal than Redis has. It would not surprise me if ZeroMQ would be a magnitude faster.

On the other hand, if you expect only a handful of listeners, really want message persistence and don’t care that much about latency I think Redis could be a viable option as it will make your design very simple.

I’ve been using Redis so far only for it’s Key-Value store and it’s awesome for that type of usage, but i was considering using it’s pub/sub features as well. However your comment made me stop and think.

I believe that the more people that will use and try it the more user friendly it will become because of the community effort. I am not sure if I will call it ‘hype’ that surrounds ZeroMQ, but there sure are a lot of people getting excited about the (funded) strong performance claims of 0MQ.

I think such excitement is a requirement for any young project to grow. Don’t get me wrong, I think it is good that you point to some of the more negative aspects of ZeroMQ and I must admit that I purposely left out that 0MQ still is a young project. But I think the following quote applies here: “If you want to build a ship, don’t drum up people to collect wood, divide the work and give orders. Instead, teach them to long for the endless immensity of the sea.”

I agree with both of your points, that indeed the documentation is lacking somewhat but that the struggle with the documentation is worth it. Also, there is a wiki on zeromq.org so I expect that a community effort will solve the documentation aspects at some time.