TL;DR :O encadeamento único torna o redis mais simples e o redis ainda é vinculado à E/S.
A memória é E/S. O Redis ainda está vinculado à E/S. Quando o redis está sob carga pesada e atinge o máximo de solicitações por segundo, geralmente fica sem largura de banda de rede ou largura de banda de memória e geralmente não usa muito da CPU. Existem certos comandos para os quais isso não será verdade, mas para a maioria dos casos de uso, o redis será severamente limitado por E/S pela rede ou memória.
A menos que as velocidades da memória e da rede subitamente fiquem muito mais rápidas, ser de thread único geralmente não é um problema. Se você precisar escalar além de um ou alguns threads (por exemplo:configuração master<->slave<->slave), você já está olhando para o Redis Cluster. Nesse caso, você pode configurar uma instância de cluster por núcleo de CPU se estiver de alguma forma com falta de CPU e quiser maximizar o número de threads.
Não estou muito familiarizado com a fonte ou componentes internos do redis, mas posso ver como o uso de um único thread facilita a implementação de ações atômicas sem bloqueio. Os threads tornariam isso mais complexo e não parecem oferecer grandes vantagens, pois o redis não é vinculado à CPU. Implementar a simultaneidade em um nível acima de uma instância do redis parece uma boa solução e é com o que o Redis Sentinel e o Redis Cluster ajudam.
O que acontece com outras solicitações quando o redis demora muito?
Essas outras solicitações serão bloqueadas enquanto o redis concluir a solicitação longa. Se necessário, você pode testar isso usando o
client-pause comando. 
