Há ganho de performance com Blazor. Não é tão grande porque para manipular o DOM precisa chamar o JavaScript, mas quem sabe um dia arrume isso. Também não é tão grande porque porque o WebAssembly não está com tudo o que prometeram e está andando devagar, então ele tem que usar seu próprio GC em vez de usar o do browser. Apesar de tudo isso, em alguns casos pode ser várias vezes mais rápido que JavaScript.
O WebAssembly está funcionando melhor fora do browser do que dentro. E por isso muita gente o está adotando de forma generalizada, o que não é o fim do mundo, mas eu acho um erro. Mais um da área. Espero que melhore mais no browser.
O maior motivo para se adotar o Blazor é usar a mesma tecnologia do servidor e ficar na tecnologia que a pessoa já domina. Isso tem ganhos de produtividade e eficiência no servidor em comparação a adotar Node/Deno.
O Blazor tem alguns modos de operação e cada um pode ser melhor para cada problema que quer atacar.
Não é uma tecnologia sem desvantagens. Precisa analisar com profundidade antes de adotar, tem que olhar todos os pontos relevantes para cada cenário, não pode só olhar as vantagens.
Particularmente eu tenho olhando outras soluções, mas são complicadas porque não tem nada pronto, e acho que deveria ter, seria um passo na direção certa.
Note que eu sou defensor de que a aplicação raramente fica tão boa no browser, mas é uma batalha perdida. Eu acho que JS cai como uma luva em websites. Quando vai fazer aplicação, nem deveria rodar em um browser.
Mas se vai rodar por a aplicação nele então o TypeScript deveria ser adotado. Em alguns casos o C# ou outra tecnologia que usa WebAssembly deveria ser adotado.
Mas na maioria desses casos deveria adotar uma solução que não usa o DOM, ou seja, o browser é só um um suporte, mas não vai usar nada da API de tela dele. Existem soluções prontas para isso, mas não populares, não mantidas de forma que você possa confiar. Portanto, para a maioria das pessoas não é uma solução real, ainda que seria a melhor já que a escolha de rodar em browser já foi a errada. Não vou entrar em todos os detalhes aqui, porque nem é o foco.
As pessoas não entendem que dá para fazer um aplicativo nativo com quase todas as vantagens de rodar em um browser, e muitas outras. Ela terá pequenas desvantagens, mas as vantagens ajudam mais. Claro, para ter todas as vantagens precisa saber o que está fazendo e dá um pouco mais de trabalho porque ninguém entregou pronto. E não entregam pronto porque todo mundo fugiu do nativo sem um motivo real. Nossa área é pródiga em tomar decisões erradas por desconhecimento.
O MAUI é a solução correta? Difícil dizer. Pode ser. Não dá para comparar ele com linguagens, pela simples razão que ele não é uma linguagem. Não é tão simples decidir o que usar. Precisa de uma análise minuciosa do cenário, precisa estudar muito todas as tecnologias, o problema, o usuário, o mercado e outros pontos. Em geral a pessoa tomará a decisão errada porque ela não quer fazer isso. Ou será errada porque só ouviu a indicação de alguém que não tem compromisso algum com essa solução.
Tem diversas outras soluções para C#, além das soluções que não usam C#. Em geral sempre haverá grandes diferenças em cada uma.
Blazor ou MAUI são ótimas tecnologias, mas não podem ser adotadas em todos os projetos. Tem tecnologias que vão se encaixar melhor ou não. Tem caso que será meio que um "tanto faz", até porque os problemas do projeto podem ser muito maiores em outras questões.
Faz sentido para você?
Espero ter ajudado.
Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).