That is harder when each service and team has their own repo and review process. Doesn't mean they won't just get merged, but there is increased friction and less-trust about random PRs from engineers that aren't actively working on the same team, so those PRs might get more scrutiny.
Agreed - ther is no reason for that not to be the case. It just is that in practice (and not as some essentialism of how organizations needs to structure things) that miroservices tend proliferate git-repos and modules tend to be part of monorepos. But, sure, there is no need for that to be the case. So given a world like that, the repo seperation is what enforces the friction for junior devs to submit changes across repos. With monorepos it is easier.
