I have an opinion that, as everything else in software, depends:

If there are tens of teams working on the same repo, it's chaotic. Separating into smaller ones makes it easier to deploy, specially when there are db migrations involved.

If there are fewer teams, there's two approaches: monolith monorepo, or monorepo with separate projects, but with single deployment pipelines. I prefer the latter, as testing changes and deployment isn't as chaotic. I also prefer when each subproject has it's own DB, so the migrations can be separated. There's nothing I hate more than dealing with migration conflicts