Eu concordo plenamente com isso.

Eu já utilizei React e NextJS para criar alguns WebApps ao mesmo tempo que também tinha que desenvolver o backend com NodeJS, Python ou PHP.

Depois de fazer uma análise profunda, não vi a menor necessidade de construir aplicações com o frontend desacoplado do backend, uma vez que criava as soluções na maioria das vezes sozinho, não era um projeto que iria ter uma alta carga de requisição...

Hoje estou usando uma única Stack (Django completo no backend e no frontend com Django template) estou integrando algumas tecnologias como o AlpineJS e outras libs para dar o mínimo de dinamismo as UI.

Percebo que a minha produtividade aumentou muito, diminui a complexidade do ambiente de desenvolvimento, e o debug do Django integra tanto o frontend quanto o backend.

Claro que sim existirá casos onde o backend será criado para prover endpoint para "N", aplicações, nesse caso uso o Django Rest Framework.

Tem de tomar cuidado com esses programadores 20 anos mais de carreira kkkkk.
Eu tenho 30 anos de carreira como programador e consigo entender que depende muito de varios fatores para que uma estratégia como SSR, SPA ou outras seja adotada se nao tomar cuidado com esse pessoal daq a pouco vcs vao estar programando em BASIC com MSDOS de novo hahahahah. Sucesso a todos.

• "o desenvolvimento é mais ágil: um repo, um build, um deploy." Não entendi a lógica de como ter um build e um deploy deixa o desenvolvimento mais ágil. Não é como se em um sistema com back e front separados toda atualização em um implicasse em atualização no outro (exceto especificamente para mudanças nos acordos de API). Na verdade, como eu disse no post, nestes cenários, ter duas pipes separadas que possam rodar em paralelo faz o deploy mais rápido pois cada pipe executa apenas em cima do código que deve assegurar a qualidade. Em um mono repo, uma mudança na camada de view vai triggar uma pipe que vai analisar (SAST, DAST, testes, etc) ela e todo o resto do sistema desnecessariamente, consumindo mais tempo e dinheiro.
• "Menos npm e menos dependência de terceiros = menor superfície de ataque e menos CVEs." De acordo. Entretanto, fico pensando em quão grande realmente seria essa diferença. Um projeto Angular, por exemplo, em 90% dos casos vai necessitar apenas de uma lib de UI além dele próprio. Ter um mar de deps de terceiros é algo característico do React.
• "A equipe pode ser menor e mais generalista, o que reduz custo e complexidade." De acordo. Porém, isso não é válido apenas para monorepos SSR. Mesmo que os backenders de plantão torçam o nariz pra essa realidade, muitos projetos hoje nascem tendo o front/UX como centro do produto e necessitam de apenas um CRUD básico, então ao invés de terem um time de backend eles simplesmente plugam o firebase e supabase pra ter toda API pronta. Ou seja, esse mesmo argumento hoje já vale também a favor do SPA sem um repo pra backend.
• "SSR aguenta bem com cache, CDN e otimização de banco." As 3 práticas são válidas pra qualquer sistema web e beneficiam igualmente um SPA. Se anular o efeito destes 3 e isolar apenas o comportamente específico de SPA vs SSR, o SSR ainda vai ter mais latência para servir conteúdo, já que o SPA já tem tudo carregado localmente e busca apenas informações de forma granular (ainda mais granular se estivermos considerando GraphQL).
• "SSR tradicional pode evitar duplicar regras em dois lugares diferentes." De acordo. Existem casos específicos onde vejo vantagem nisso, mas no geral é um impecilho, de fato.

Enfim, meu ponto todo no post foi tentar mostrar duas coisas:

1. É errado dizer que monorepos SSR satisfazem as necessidades de todos projetos modernos;
2. Dizer que um projeto é possível de ser realizado em monorepo SSR é diferente de dizer que ele vai ser melhor por isso.