Just to clarify, there is no polling in redis blocking list ops. I believe the pub/sub doesn't require polling either.
Given that, I can think of a lot cases where Redis will work fine as a messaging server. If you need a very sophisticated routing mechanism, you will need to look at a more dedicated solution. But if you can express the message routing in either the rpush/blpop style or in redis pub/sub, why not?
We've found the primitives that redis gave us to be sufficient even for a fairly complex routing design.
Rabbitmq (which we used previously) might still have an edge for very complex scenarios, but AMQP is generally a royal pain and we've had serious issues with rabbitmq reliability under load (and debugging the problems thereafter!).
Consequently we switched our hairy mix of bindings to a straightforward "LPUSH to everyone whom it may concern" and wouldn't look back.
That may be less efficient in theory, but the machine-load (i/o, CPU) went from "uh oh" to "barely measurable" for us. Even more importantly we now feel to have a much better grip on the system because if something goes wrong then we'll know where to look. In contrast rabbit was effectively a blackbox, which turned into a huge problem once it ceased to "just work".
