Not when it gets compiled from scratch all the time, or is open to spaghetti code modifications.

Modular code in subdirectories is what gave microservices an excuse against the "monolith".

It can work either way. There are pros can cons to both ways, code organization needs to be done correctly either way. Nothing about either ensures your code is a good modular structure vs a haphazard mess. In most cases code in fact has a modular structure behind it that is followed - but the structure is not always good (something that is easy to see in hindsight, but the wrong rules were put in place early and now it is hard to change)

Mono repo makes violation of modular rules easier, just link it in - in a complex project odds are nobody will notice. However this doesn't mean monorepo is bad, it just needs that you need to be careful to ensure the rules are written down.

Multi-repo makes violation of those same rules harder - you have to make a bunch of changes to ensure that the bad dependency is in the environment. This hints at the downside of multi-repo: you need to have some sort of dependency management system to ensure that the right version is there when you build.

Subdirectories can belong to different repos. In modern IDEs like Intellij or Eclipse it's possible to work with multiple project roots in the same window (e.g. if you have a common library for microservices and want to redesign its API and make changes everywhere at once). The good thing here is that in most cases you work with just a fraction of your code and with a single project root, switching to multi-project view only in rare big reengineering tasks.