conversando com alguns colegas descobri que essa recomendação é mais pra projetos grandes, com times separados, e pra criar um micro-SaaS próprio é ideal manter tudo em um repositório só (separando em duas pastas "frontend" e "backend")
Eu não tomaria isso como regras universais, pra mim a melhor resposta é "Depende".
Já vi projetos pequenos em que as funcionalidades eram separadas. E projetos grandes com tudo junto (com as partes/módulos/chame-do-que-quiser cada uma em sua própria sub-pasta).
Separar pode deixar mais organizado, mas e quando tem muitas partes em comum? Compensa criar um terceiro componente/lib/módulo/pacote só com essa parte comum e adicionar como dependência em ambas? Ou é melhor deixar tudo junto?
É o caso de um projeto recente, que tem mais de 1600 arquivos e cerca de 240 mil linhas de código, somando front e back (portanto não diria que é "pequeno"). Ele é dividido em dezenas de módulos, e há muita dependência entre eles, além de dependências transitivas em comum - ou seja, as mesmas configurações ficariam duplicadas em mais de um módulo, caso fossem separados.
Neste caso, decidiram deixar tudo junto mesmo. O build já cuida de compilar e empacotar cada um junto com suas dependências, além de ter a possibilidade de se fazer o build individual, caso necessário.
Mesmo que hajam times separados, cada um mexe em um dos módulos por vez e não há tantos conflitos. Neste caso, é um problema de gerenciamento, de não deixar mais de uma equipe mexer nas mesmas coisas ao mesmo tempo. Pois se vc não faz esse gerenciamento, nada impede que diferentes equipes mexam nas mesmas coisas, independente de ter tudo junto ou separado.
Se não houvesse tanta interdependência, talvez tivessem optado por separar alguns módulos, ou talvez todos. Mas neste caso foi mais vantajoso manter tudo junto. Não atrapalha em nada o deploy, pois podemos escolher gerar o build de tudo ou apenas algumas partes, e cada pacote é gerado em sua respectiva pasta. Aí acho que tem mais a ver com as ferramentas usadas, a facilidade de configurar, etc (pra quem ficou curioso, usamos o Maven, que possui um bom suporte para projetos modulares).
Enfim, se alguém diz pra fazer (ou evitar) algo, seria bom dar uma justificativa técnica - algo melhor e mais elaborado do que "fica feio" ou "é boa prática". Tem casos que uma ou outra abordagem pode ficar melhor, e tem casos em que tanto faz.