Acho que o principal ponto para responder à pergunta "Até que ponto deveríamos apostar em frameworks como solução? " é entender o contexto em que estamos. Frameworks podem ser usados em diversos tipos de situação e podemos abordar seu uso de forma diferente em cada uma.

Vamos levar em consideração que temos uma ideia de produto e queremos valida-la o mais rápido possível para poder gerar receita o quanto antes. Nesse cenário temos que nos fazer a uma pergunta: "qual problema buscamos resolver com um framework?". A resposta nesse caso deve levar em conta a velocidade que precisamos ter no desenvolvimento do produto, então vamos utilizar um framework para agilizar esse processo, além de nos ajudar a seguir padrões que outros desenvolvedores vão conseguir entender futuramente por já ser algo convencionado pela comunidade da tecnologia escolhida.

Então alguns meses se passam e conseguimos validar que nosso produto gera valor e já temos clientes pagantes. É hora de melhorarmos o produto adicionando funcionalidades novas que serão úteis aos usuários. E novamente o framework nos ajuda a entregar rápido e gerar cada vez mais valor aos nossos clientes.

Mais meses se passam e agora o cenário é diferente: queremos continuar melhorando o produto, mas esse trabalho parece cada vez mais árduo, por termos usado e abusado do framework desde o começo do projeto agora temos uma base de código muito grande e desorganizada, não há uma separação muito clara do que cada função faz, muitas funcionalidades estão acopladas a outras sem necessidade e o software é difícil de ser testado e mais ainda de ser alterado, pois parece que estamos sempre brigando com o framework, que outrora foi nosso melhor amigo.

Agora é hora de dar outro passo: vamos estudar melhor sobre arquitetura de software e boas práticas para ter um código escalável e fácil de manter. Vamos sentar com o time e pensar em uma forma de deixar a lógica de negócio do nosso projeto separada do nosso framework.

Mais alguns meses se passam e terminamos o árduo trabalho de organizar nosso código, acho que agora podemos voltar à questão: "qual problema buscamos resolver com um framework?". Acredito que a resposta é bem simples nesse cenário: "resolver os problemas que o framework foi feito para resolver".

Pode parecer idiota, mas no fim é assim que devemos encarar frameworks. Eles são uma abstração para problemas comuns no cenário para o qual foram desenvolvidos.

Vamos tomar o Vue, um framework frontend, como exemplo: o Vue é uma solução que nos ajuda a abstrair muito do trabalho que temos ao desenvolver interfaces web, nos dando acesso a reatividade e a componentização de elementos do sistema a fim de tornar a interface mais modular. Obviamente conseguimos fazer esse tipo de coisa apenas com JavaScript, mas sabemos que manter um projeto muito grande feito dessa forma, ainda mais com várias pessoas mexendo no projeto, pode ser uma tarefa bem complicada.

E aí que está: o Vue quer resolver problemas relacionados à interface do usuário e nos ajudar a dar uma melhor experiência de desenvolvimento para criar interações melhores, além de estipular conceitos e boas práticas que qualquer programador que for utilizar a tecnologia deve seguir. Toda a lógica de como vamos lidar com os dados de entrada do usuário podem ser feitas dentro do próprio componente que criamos, mas não significa que devemos fazer isso, visto que podemos simplesmente delegar essa tarefa para as camadas de domínio da nossa aplicação.

O mesmo se aplica para frameworks backend, como o Express ou NestJS, por exemplo. Ambos foram criados para auxiliar na parte mais básica na criação de uma aplicação server-side: criar rotas de API, middlewares, renderizar telas etc. Esse tipo de coisa é comum em praticamente qualquer aplicação que rode no servidor, então por que não utilizar algo que facilite esse processo?

Em resumo, nosso produto não precisa saber o que são rotas, métodos HTTP , uma query SQL ou mesmo elementos do DOM, então nossas regras de negócio não devem estar acopladas a isso. O papel do framework deve ser apenas fazer uma interface com o usuário, recebendo e enviando os dados de volta.

Como exemplifiquei no início, obviamente faz sentido deixar tudo muito próximo do framework quando queremos ser rápidos na entrega, mas acredito que quanto mais o projeto e os desenvolvedores amadurecem, mais devemos tratar o framework apenas como uma interface para o que de fato gera valor na nossa solução.