As aplicações em SPA tem um problema essencial. Como toda a renderização da página fica a cargo do JS, conforme a aplicação cresce, maior fica o bundle gerado que é enviado ao cliente. É comum o bundle de grandes aplicações terem vários MBs. E isso impacta várias coisas, como o tempo de carregamento, consumo de banda e até o SEO.

Por isso essas soluções SSR tem sim aplicação e fazem sentido. Em todos os casos? Não. Você poderia utilizar apenas em páginas públicas. Mas seria uma complexidade a mais desnecessária você ter 2 aplicações distintas, trabalhando de formas diferentes, para atingir o mesmo objetivo. Se você já tem um servidor que faz o trabalho pesado de converter o JSX em HTML/JS e servi-las, então adicionar mais páginas não seria algo necessariamente ruim. Além disso, essas ferramentas simplificam partes que originalmente ficariam a cargo do Backend, como a autenticação, e trazem recursos como otimização de imagem (que só deve ser feita em páginas públicas). E não, não é apenas fazer como se fazia antes, pois os recursos basilares das SPAs, como o Client Side Routing, e manipulação do DOM ainda estão presentes. Na verdade, essas ferramentas permitem que o desenvolvedor Front End continue trabalhando como se fosse uma SPA, mas agregando a renderização pelo servidor.

O maior problema na verdade, agora falando do Next, é que existe essa visão de dependência da Vercel. Na realidade, a Vercel é uma empresa de Cloud que utiliza o Next como uma isca para os seus clientes. Mas isso não quer dizer que você obrigatoriamente depende deles. O Next pode rodar, tranquilamente em uma instância EC2 ou utilizando o Amplify. Ou até mesmo e em ambiente On Premises, se for o caso.