Probably the less complexity also means a much bigger amount of messages per core.
With Redis in an entry level Linux box you can process 100k messages per second per core. I'm not sure if current AMQP systems can handle this amount of messages with commodity hardware.
Another reason why Redis can be a good approach I think is that it is a simple system: simple to understand, simple to deploy, very stable. There is support for Pub/Sub. It also supports many other data types, so for instance, want a priority queue? Do it with a sorted set. What some special semantic for your message passing? possibly with BRPOPLPUSH you can do it. And so forth.
A common case of this flexibility is shown by RPOPLPUSH (without the "B" so the non blocking version). Using this command with the same source and destination list will "rotate' the list providing a different element to every consumer, but the data will remain on the list. At the same time producers can push against the list. This has interesting real world applications when things must be processed against and again (fetching RSS feeds, for instance).
So Redis is a pretty flexible tool for messaging, and I think there are for sure great use cases for AMQP but with big overlaps with Redis, and also with use cases where Redis is definitely a better alternative.
