E aí parente, rs. Aquela velha frase: "depende da aplicação". Atualmente, trabalho em um projeto aonde o front-end é feito em React e o core da aplicação é exibir em tempo real através de dashboards, informações de centenas de dispositivos IoT. Pelo menos aqui, o conceito de Server Components não se aplica. Caso fosse migrar pra Next, teria que escrever em praticamente todos os componentes a diretiva 'use client', o que ao meu ver, não faz sentido, melhor deixar tudo como CSR.

Agora falando sobre compartilhar interfaces, realmente isso na prática acaba sendo um problema, pois as mudanças nas estruturas entre projetos de back-end e front-end precisam estar sempre sincronizadas. O back-end deste projeto é com ASP.NET 6, então já viu né, as interfaces dos modelos e DTO's tanto do TS e do C# precisam estar iguais, e é um saco quando precisa mudar algo em 2 lugares, seria muito melhor mudar em 1 lugar só.

Outra coisa é que já fizemos algumas POCS aqui pra ver se um "full-stack" funcionaria na prática, e até agora, não deu certo. Com o nodejs no backend, seus ORM's entregam "menos" do que o Entity Framework, mas o pior nem é isso, é que as ferramentas do mundo de automação industrial (usadas no IoT) funcionam melhor no ecossistema da MS. E falando em MS, testamos o Blazor para avaliar como seria a experiência de desenvolvimento de interfaces e é até legal, só que aí tu vai usar uma lib como MuiBlazor e se depara com muitos componentes faltando e bugados. Por outro lado, o MUI do React é muito mais consolidado e funcional.