Cara, primeiramente parabéns pela coragem de expor suas idéias e opiniões tão fortes assim em um fórum, de fato vai de contra-mão com o que a comunidade acaba indo, mas eu gosto de pensar como você, fora da caixa, acho que é assim que as coisas melhoram, não apenas seguindo cegamente pra uma tendência, ainda que estando no jogo, precisamos muitas vezes jogar pra não ficar de fora também, como você já sabe bem.

As dores...

Eu compartilho das mesmas dores que você com relação à complexidade desnecessária trazida pelos frameworks e outras bibliotecas. Eu realmente vejo no dia a dia o quão fácil é fazer as coisas da forma mais tradicional ou nativa, porém também nao acredito que javascript vanilla é a solução.

Isso não é um problema só do front, na vida, tudo usamos ferramentas, fazer sem o apoio das ferramentas é de fato não conseguir ser produtivo e muitas vezes não conseguir nem resolver os problemas, imagina a construção civil, medicina, biologia, etc sem instrumentos. Não é uma questão apenas da nossa área. Não acho que a linguagem tem o papel de resolver todos os problemas, ela pura assim como uma série de api's tem um propósito de servir como base.

Talvez, pra muitos casos trabalhar só com o vanilla seja super suficiente, mas eu tomaria um certo cuidado pra estrapolar pra todos os casos.

Minha visão

Eu acho que a linguagem, as ferramentas, e uma série de bibliotecas já evoluíram muito a ponto de que resolver uma gama muito grande de problemas, então a classe de problemas que necessitam de frameworks é muito menor hoje.

Percebi que trabalhar com o Js puro é sim potencializar o problema de deixar o código mais desorganizado em geral, porque não são todos os devs que tem preocupação ou experiencia pra deixar o código estruturado, o framework ajuda um pouco nessa estrutura inicial, deixar o código com a mesma carinha, mas eu concordo com você isso não é totalmente garantidor de ter um código bem estruturado, mas é um pouco mais estruturado, você ganha um pouco de familiaridade sim se você trabalha com aquele framework, o que com certeza não ajuda muito, se você não trabalha com aquele framework específico.

Complexidade

Existem várias formas de identificarmos complexidade, ainda que seja um conceito subjetivo. A minha visão sobre complexidade tem haver com a estrutura do framework.
Eu gostaria de compartilhar a minha visão com relação ao o que eu considero como complexidade.

Angular

O Angular tem uma complexidade inerente ao framework que é trazer uma série de conceitos back-end que não necessariamente casa com os tipos de problemas que existem no ambito de UI. É como vc usar conceitos MVC em uma aplicação de Jogos, não faz sentido, porque a forma como se abstrai os problemas nesse contexto é diferente.

Vuejs

Tem muito pouca personalidade na minha visão. Ele tem tantas formas diferentes de resolver os problemas que ele traz uma complexidade e falta de padronização que é justamente o que se espera de um framework. Voce pode usar SFC ou pode usar jsx, pode usar orientação à objetos, pode usar a forma funcional, tem os hooks assim como React, então além de ter a sua cara apenas pra fazer as coisas, tem a cara de outros Frameworks, como hooks do React... então fica um frankenstein de conceitos.

React

O react resolve um problema clássico que é, escrever da mesma forma os componentes html no lado do server side, seja gerando estático, seja servindo como SSR, e a mesma estrutura de código ser usada para os problemas client-side.
E isso ao mesmo tempo que resolve um problema, ele gera outro, que é misturar renderização de html estático com a lógica em si.

Então, antes voce separava os conceitos ou interesses, como usar um template engine pra renderizar o front, usando sei lá, Pug, PHP, Erb do Rails, ou qualquer template system, toda a complexidade e coisas com relação a importação de html, imagens, svg's etc ficavam por conta dessa parte. Quando o javascript entrava, ele se preocupa apenas na adição de eventos, na orquestração das mensagens e gerenciamento de estado etc.

Com essa mescla de "concerns", não é incomum vc ver componentes com vários imports nos arquivos de componentes, que fazem parte de renderização e também com relação à lógica, então o componente fica enorme e muitas vezes a saída é mais complexidade, quebrando em mais arquivos.

Além disso, com a biblioteca invadindo a parte de renderização além da lógica, ela te força a usar metaframeworks como Next ou algo do tipo pra poder renderizar no server-side, voce fica preso no JSX e à um servidor node, não é como era antigamente, onde a partir do html já existente, o js fazia sua mágina, o JS é dependente desse html dentro do código, inclusive fazendo com que o bundle fique enorme, porque toda a sua aplicação fica dentro do seu javascript.

Com tudo isso, você perde completamente o valor de pensar em fazer as coisas de forma separada, inclusive pensar em como montar UI systems / Design System de forma apartada fica dificil com esse framework, porque o componente tem que já nascer com o html e css embutido, importado dentro do js. Então cria-se o que a gente chama de Vendor Lock-in.

Se seu time precisa pensar em criar um design system, ele já sai de fábrica acoplado à um framework e só será compatível com aquele framework.

Isso força o Dev a não pensar mais de maneira desacoplada, porque ele foi "ensinado" à pensar de forma acoplada com um framework.

Design systems mais desacoplados, como Bootstrap, Foundation, Material UI, Semantic UI poderiam ser usados como referência na hora de você pensar em criar um design system personalizado e assim poder distribuí-lo para que as equipes pudessem trabalhar em páginas usando qualquer tipo de framework, desde que importando o css base daquele produto.

Considerações finais

Além de tudo isso, desde o início esses frameworks foram responsáveis por trazerem uma visão statefull da aplicação como um todo o que é trazer ainda mais complexidade, através da idéia SPA. E no final, muita complexidade é trazido por conta disso, fazer toda a aplicação estar em memória e trackeado pelo framework, problemas de memory leak porque a página nunca recarrega etc etc...

E sempre foi algo que eu fui meio contra, desde o início, sempre desenvolvi criando páginas estáticas, porque recarregando a tela, vc tira uma série de complexidades que vc não teria, e existem várias técnicas pra fazer a transição das páginas suave.

E na prática a conclusão que se chegou é que ir pra linha de geração de estáticos se tornou sendo o caminho mais inteligente hoje, porém, muitas aplicações foram pra esse caminho sem a menor necessidade e hoje são legados.

---

Eu compartilho das mesmas dores que você, no final eu também quis contribuir de alguma forma para ao invés de ficar só reclamando e apontando esses problemas, tentar resolver esses problemas e compartilhar com a comunidade, e como vc abriu espaço, compartilho aqui a minha: https://jails-js.org/

No meu caso, eu já usei tanto nas empresas que trabalhei, como também com projetos próprios, ele me serviu inclusive pra defender a idéia de que é possível fazer aplicações complexas sem necessitar necessáriamente de frameworks como o que temos hoje. Nesse projeto eu queria mostrar que é possível ainda ter soluções que geram html, seja server-side, seja estático, usando qualquer tipo de template system e ainda assim poder usar um js mais estruturado para a lógica... Ainda acredito que é mais saudável, separar html, css e js, para poder criar projetos que podem ser consumidos e compartilhados inclusive com outros frameworks.

Valeu!