Como quase todo mundo aqui, você está emocionado. Claro que não são a mesma coisa, senão eles não exisitiriam. Alguns pontos são válidos, eu sou muito contra usar NoSQL, eles nunca se provaram, mas você exagerou quando cruzou a linha dos bancos de dados, vamos por partes.

Cache: qual é o sentido de usar o seu próprio banco de dados pra cache se uma das funções do cache é diminuir a carga no banco? Um banco relacional é um recurso relativamente difícil de se escalar, o ideal é não precisar escalar horizontalmente e em muitos casos, você precisa do mesmo dado em 80% das consultas, então um Redis encaixa muito bem, já com estratégia de TTL embutido pro seu cache ser volátil

ElasticSearch: ser o mesmo algoritmo de busca, não significa ser o mesmo sistema de armazenamento, fora que muitas vezes ele é usado pra logs e você NÃO DEVE manter logs no banco em produção.

DynamoDB: ele não é chave-valor, ele é um monstro, mas que ninguém sabe usar, então, não use se quer um banco chave-valor.

Kafka: você não deve usar o seu banco em mais de um microsserviço, isso vai contra a própria arquitetura, fora que o Postgres não tem o melhor recurso do Kafka, porque ele não é um sistema de mensageria. O zero copy do Kafka é absurdo, ele quase não usa CPU e memória, trabalho em uma multinacional e o Kafka serve a toda a companhia, OLTP e OLAP, sem cair, sem precisar escalar, porque ele simplesmente joga o dado direto na interface de rede, sem copiar pra memória várias vezes

No seu site, você mencionou até o Airflow, não misture OLTP e OLAP, isso é feito também pra deixar o banco pra aplicação, não use seu banco relacional pra gerar relatórios, a menos que a empresa seja de fato pequena e se for pequena, ninguém vai inventar um Airflow.

No geral todas as ferramentas existem, porque se usar um banco relacional pra cada, será um desperdício de recurso, você não pode usar o seu banco pra tudo isso, ele não aguenta