É a mesma coisa sobre engines/runtimes Javascript. Sou "javascripteiro" e não tenho vergonha de assumir.
bun.sh tá num olofote gigantesco, princípalmente no twitter. Um pouco causado pelo proprío marketing da equipe do bun, no qual Deno não tem muito. Por exemplo, bun lançou o bun shell que é um utilitário built-in que permite executar comandos shell, diretamente do javascript/typescript. Só que isso é algo que Node.js já fazia com o zx da Google, e para o Deno, existe a alternativa Dax, que faz o mesmo.
Ou seja, bun, faz parecer que tudo é uma super novidade, quando na verdade não é... Notem que eles raramente colocam nos seus posts no twitter, algo como "inspired by...".
Jarred Sumner que é um dos cabeças por trás do bun. Só vive postando benchmarks e números surpreendentes na tentantiva de evidenciar o quão bun é mais veloz que outros runtimes e ferramentas.
Eu não acho isso ruim, na verdade e bom que haja uma alternativa de Runtime Javascript que foque no desempenho, já que Javascript por natureza não é tão veloz assim. Só que obviamente, tem uma galera que dá muito valor a isso. Ao tempo de execução de algo, quando na prática, diversos outros fatores vão importar as vezes até mais.
Deno parece evoluir mais devagar? aparentemente sim. Há muitas bibliotecas para Deno que mais parece uma reinvenção da roda, do que qualquer outra coisa. Há muitas bibliotecas que parece que foram criadas porque simplesmente a abordagem inicial do Deno, foi não considerar total compatibilidade com o ecossistema Node.js (coisa que bun, começou considerando). Por uma razão obvia, garantir essa compatibilidade poderia fazer com que o Deno se aproximasse novamente dos problemas que Node tem, e portanto, seria mais outro runtime Node sem sentido.
Node, Bun ou Deno
Node: Na prática vai do que você tá buscando. Node.js um setup inicial gigantesco para um projeto, diversas dependências para fazer algo, node_modules inchada, etc. Porém é o runtime com maior compatibilidade e o mais confiável para empresas que usam Javascript no lado servidor, por ter mais tempo de maturação. pelo menos por enquanto.
Bun, muitas "inovações" que não são tão inovações assim, na verdade, eles fazem parecer que são. Dentre essas opções, bun é o que tem maior marketing, e isso trás resultados, como por exemplo lodash que declara compatibilidade com bun, enquando pra Deno nada por enquanto. Bun também, parece ser um runtime que visa muito desempenho, e tornar Js algo mais sério em termos de perfomance no lado servidor. Porém, não se iludam com isso. Bun tornou o tempo de instalação de bibliotecas mais rápido que os concorrentes, eliminando diversas etapas de verificação e integridade, ou seja, eliminou mais código. Bun se demonstra mais rápido em diversos benchmarks mas isso não é 100% mérito do Bun, exemplo, o web service do bun é integrado pelo uWebScokets.js escrita majoritariamente em C++. Outro fato que dá pra pontuar, é que Bun é algo recente, e por tanto, a quantidade código é menor e relação aos outros runtimes, isso não siginifica que o código não pode aumentar, e esse desempenho que é tão pregado, pode acabar se tornando algo não muito relevante ou até mesmo se equiparar com os outros runtimes.
Deno: Se você quer uma developer experience maneira, e coisas legais para newbies, como um configurador de cron unix integrado, vai de Deno. Deno eu considero ser o meio termo entre Node e Bun. Deno não é tão maduro como NodeJs mais mais maduro que Bun. Ou seja, deno se aproxima mais do Node.js em questão de confiança do que bun. Deno tem um design de bibliotecas padrão, muito satisfátóro e fácil de entender, literalmente qualquer newbe consegue utilizar. Tanto da biblioteca padrão, quando to namespace Deno. Deno é mais rapído que node em certos aspectos mas em outros é pior que node, a citar um exemplo, a transferências de arquivos em rede os famosos Streams, ainda conta com issues abertas no github. Deno tenta abraçar algumas features, e tenta trazer de forma built-in, porém não faz isso de uma maneira tão satisfatória, um exemplo é o formatador de código padrão do Deno, já se mostra muito mais limitado que o novo BiomeJs, o que pra mim, já nem faz sentido utiliza-lo.
Minha recomendação
Qual runtime utilizar, vai depender muito de que entidade você é. Você é uma equipe, uma empresa que precisa desenvolver uma produto rapído e por em produção. Com certeza a melhor opção será o Node. Muito difícilmente você vai arriscar comprometer sua equipe, por conta de uma falha no runtime novo ou por falta de compatibilidade com bibliotecas mainstream. A citar um exemplo, a minha preferência pessoal é o Deno, só de não ver a gigantesca pasta node_modules na minha raiz, já me agrada muito. Porém reportei um problema na biblioteca padrão de testes em que objetos eram dados como não iguais, mesmo quando eram iguais. O problema está corrigido mas ainda sim, a liberação da correção, não é tão rápida. Imagine que sua equipe estivesse dependente de uma biblioteca como essa, com menor maturidade como Jest?
Se você é um desenvolverdor solo, gosta de experimentar mesmo que encontre alguns bugs e obstáculos pelo caminho, aí tanto faz, Bun ou Deno. Deno vem me atendendo e tem recursos buil-in muito interessantes. A minha recomendação, é que você desenvolva uma arquitetura de código que permita trocar fácil entre Node Deno ou Bun a qualquer momento, sem muito custo. Tente isolar as chamadas ao namespace padrão do seu runtime, e tente depender pouco deles.
Isso aqui era pra ser uma resposta, e acabou virando uma publicação rs, xD.