Aqui está o que eu encontrei ao tentar responder a essa mesma pergunta. Provavelmente não é abrangente e pode até ser impreciso em alguns pontos.

Em suma, o RQ foi projetado para ser mais simples. O aipo foi projetado para ser mais robusto. Ambos são excelentes.

• Documentação. A documentação do RQ é abrangente sem ser complexa e reflete a simplicidade geral do projeto - você nunca se sente perdido ou confuso. A documentação do Celery também é abrangente, mas espere revisitá-la bastante quando estiver configurando as coisas pela primeira vez, pois há muitas opções para internalizar
• 
  Monitoramento. O Celery's Flower e o painel RQ são muito simples de configurar e fornecem pelo menos 90% de todas as informações que você deseja
  
• 
  Suporte ao corretor. O aipo é o vencedor claro, o RQ suporta apenas o Redis. Isso significa menos documentação sobre "o que é um corretor", mas também significa que você não pode trocar de corretor no futuro se o Redis não funcionar mais para você. Por exemplo, o Instagram considerou Redis e RabbitMQ com aipo. Isso é importante porque diferentes corretores têm garantias diferentes, por exemplo. Redis não pode (no momento da escrita) garantem 100% que suas mensagens sejam entregues.
  
• 
  Filas prioritárias. O modelo de fila de prioridade RQs é simples e eficaz - os trabalhadores leem as filas em ordem. O aipo requer a ativação de vários trabalhadores para consumir de diferentes filas. Ambas as abordagens funcionam
  
• 
  Suporte do SO. O aipo é o vencedor claro aqui, pois o RQ é executado apenas em sistemas que suportam fork por exemplo. Sistemas Unix
  
• 
  Suporte de linguas. O RQ suporta apenas Python, enquanto o Celery permite enviar tarefas de um idioma para um idioma diferente
  
• 
  API. O aipo é extremamente flexível (vários backends de resultados, formato de configuração agradável, suporte a tela de fluxo de trabalho), mas naturalmente esse poder pode ser confuso. Por outro lado, a API RQ é simples.
  
• 
  Suporte a subtarefas. O aipo suporta subtarefas (por exemplo, criar novas tarefas a partir de tarefas existentes). Não sei se RQ faz
  
• 
  Comunidade e Estabilidade. O aipo provavelmente está mais estabelecido, mas ambos são projetos ativos. Até o momento, Celery tem ~ 3500 estrelas no Github, enquanto RQ tem ~ 2000 e ambos os projetos mostram desenvolvimento ativo
  

Na minha opinião, o aipo não é tão complexo quanto sua reputação pode levar você a acreditar, mas você terá que fazer o RTFM.

Então, por que alguém estaria disposto a trocar o Aipo (indiscutivelmente mais completo) por RQ? Na minha opinião, tudo se resume à simplicidade. Ao se restringir ao Redis+Unix, o RQ fornece documentação mais simples, base de código mais simples e uma API mais simples. Isso significa que você (e potenciais contribuidores para o seu projeto) pode se concentrar no código que lhe interessa, em vez de ter que manter detalhes sobre o sistema de fila de tarefas em sua memória de trabalho. Todos nós temos um limite de quantos detalhes podem estar em nossa cabeça ao mesmo tempo e, ao remover a necessidade de manter os detalhes da fila de tarefas lá, o RQ permite voltar ao código com o qual você se importa. Essa simplicidade vem à custa de recursos como filas de tarefas entre idiomas, amplo suporte a SO, garantias de mensagens 100% confiáveis ​​e capacidade de alternar facilmente os agentes de mensagens.