"o desenvolvimento é mais ágil: um repo, um build, um deploy." Não entendi a... · GheistLycis

"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:

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

Sobre o deploy, quando digo velocidade de desenvolvimento, estou falando sobre a velocidade de entrega e não do tempo do deploy. Há casos de que verifico a API e ela está ok e o front está com erro de type no build, ou a API não passou nos testes - Preciso retornar a tesk pro dev para que ele ajuste.

Gosto de alguns pontos de vista que você expõe, porém, nos projetos em que eu participai e participo como Tech Lead tenho mais tração e validação rápida nos projetos com stacks monorepo SSR. Pode ser uma particularidade das skills da minha equipe maaaaaas, olhando para o mercado, em que temos que desenvolver, validar produto, em pouquíssimo tempo, monorepo SSR é mais vantajoso.

E na real, RARAMENTE um projeto nasce com necessidades robustas no UI. RARAMENTE um projeto já nasce com a nescessidade de integração de APIs com várias interfaces (Web, App, Desktop e outros).

Não acredito que o SPA é lento, ele tem a possibilidade de entregar uma melhor usabilidade, bate menos em rotas como o "/me" tem mais versatilidade. Mas como falei, projetos de empresas pequenas e médias são CRUDs em sua grande maioria, e pra mim, nesse cenário um framework backend já brilha.