The reasons seem to be fairly consistent regardless of the size of monorepo [1]: cross-cutting concerns (keeping commits/changes together that target a lot of different modules) and integration testing effort (testing a lot of different modules together).

These may not be problems that everyone feels as sharply, but they can be problems that nearly everyone might face at some point. Having these problems isn't even necessarily a sign of bad architecture: at some point all of your software likely has to play nice together on the same machine.

Certainly there are solutions beyond just monorepos, but monorepos are a very well understood, ancient solution (that seems to be making a comeback of sorts, despite many of the other solutions being easier and more powerful today than they were back when monorepos were about the only solution).

[1] I've seen tools like Lerna (https://github.com/lerna/lerna) used for a managing several relatively small "monorepos" lately.