They are simpler, but they do not scale.
Eventually its better to create an internal package repo to share common code, this allows rolling updates a lot easier than a monorepo does.
Smaller repos are also less stressful for monitoring and deployment tooling and makes granular reporting easier which you will eventually have to do in large projects.
Simple for small code bases, a pain and a big code smell for large ones.
Edit: Some good discussion in comments, a good one to remember is that we are talking about the common case, in a common code base people will join and leave, parts of code will start becoming abandoned, in-depth knowledge will be lost. Its easier to keep track of and learn a self contained repo with a well defined boundry rather than a folder in a large repo with no well defined boundry and possible code leaching.
From experiance i would rather not have everyone elses mistakes and forgetfulness pollute my builds, tests and PRs and pulling a giant mono repo is much more of a resource hog on your dev system.
Having defined versioning for code packages was also a nice thing to have, specially with monitoring tools to tell you when a repo starts falling behind. You dont get that with a monorepo, even if you try and enforce some form of pseudo documentation for it, time crunch will slowly chip away at the correctness of it.
They are simpler, but they do not scale. Eventually its better to create an internal package repo to share common code, this allows rolling updates a lot easier than a monorepo does.
Smaller repos are also less stressful for monitoring and deployment tooling and makes granular reporting easier which you will eventually have to do in large projects.
Simple for small code bases, a pain and a big code smell for large ones.
Edit: Some good discussion in comments, a good one to remember is that we are talking about the common case, in a common code base people will join and leave, parts of code will start becoming abandoned, in-depth knowledge will be lost. Its easier to keep track of and learn a self contained repo with a well defined boundry rather than a folder in a large repo with no well defined boundry and possible code leaching.
From experiance i would rather not have everyone elses mistakes and forgetfulness pollute my builds, tests and PRs and pulling a giant mono repo is much more of a resource hog on your dev system.
Having defined versioning for code packages was also a nice thing to have, specially with monitoring tools to tell you when a repo starts falling behind. You dont get that with a monorepo, even if you try and enforce some form of pseudo documentation for it, time crunch will slowly chip away at the correctness of it.