As filas do Rabbit residem na memória e, portanto, serão muito mais rápidas do que implementá-las em um banco de dados. Uma fila de mensagens (boa) dedicada também deve fornecer recursos essenciais relacionados ao enfileiramento, como controle de limitação/fluxo e a capacidade de escolher diferentes algoritmos de roteamento, para citar alguns (o coelho fornece isso e muito mais). Dependendo do tamanho do seu projeto, você também pode querer que o componente de passagem de mensagens seja separado do seu banco de dados, para que, se um componente sofrer uma carga pesada, ele não precise atrapalhar a operação do outro.

Quanto aos problemas que você mencionou:

• 
  pesquisa mantendo o banco de dados ocupado e com baixo desempenho :Usando Rabbitmq, os produtores podem empurrar atualizações para os consumidores, que é muito mais eficiente do que a pesquisa. Os dados são simplesmente enviados ao consumidor quando necessário, eliminando a necessidade de verificações desnecessárias.
  
• 
  bloqueio da tabela -> novamente com baixo desempenho: Não há mesa para trancar :P
  
• 
  milhões de linhas de tarefa -> novamente a pesquisa tem baixo desempenho: Como mencionado acima, o Rabbitmq operará mais rápido, pois reside na RAM e fornece controle de fluxo. Se necessário, ele também pode usar o disco para armazenar mensagens temporariamente se ficar sem RAM. Após o 2.0, o Rabbit melhorou significativamente o uso de RAM. Opções de cluster também estão disponíveis.
  

Em relação ao AMQP, eu diria que um recurso muito legal é a "troca" e a capacidade de rotear para outras bolsas. Isso lhe dá mais flexibilidade e permite que você crie uma ampla variedade de tipologias de roteamento elaboradas que podem ser muito úteis ao dimensionar. Para um bom exemplo, veja:


_{(fonte:springsource.com)}

e:http://blog.springsource.org/2011/04/01/routing-topologies-for-performance-and-scalability-with-rabbitmq/

Finalmente, em relação ao Redis, sim, ele pode ser usado como um corretor de mensagens e pode se sair bem. No entanto, o Rabbitmq tem mais recursos de enfileiramento de mensagens do que o Redis, pois o Rabbitmq foi construído desde o início para ser uma fila de mensagens dedicada de nível empresarial com todos os recursos. O Redis, por outro lado, foi criado principalmente para ser um armazenamento de valor-chave na memória (embora faça muito mais do que isso agora; é até chamado de canivete suíço). Ainda assim, li/ouvi muitas pessoas alcançando bons resultados com o Redis para projetos de menor porte, mas não ouvi muito sobre isso em aplicativos maiores.

Aqui está um exemplo do Redis sendo usado em uma implementação de chat de sondagem longa:http://eflorenzano.com/blog/2011/02/16/technology-behind-convore/