Monorepos have drawbacks and especially might become tricky to work with. Here's why.

To talk about drawbacks, we need to compare it to something else. We will compare Monorepos with Polyrepos.

Isolation / Autonomy

Monorepos force the team to build in a specific unified way. This might be good up to some point, but if your dev teams contain many diverse developers from many backgrounds, then it might have its charme to let them decide on their own what build tools and processes they want to use.

No code restriction

If you already know that you want to restrict access to certain departments, then don't choose monorepos. They will become a nightmare sooner or later.

Because if the scenario comes up one day, what can you do? You need to create another repository, that breaks the whole monorepo idea. It might be just one package that you need to restrict, but how do you deal with it? What depends on it? Will the monorepo depend on it?

Will it just be this one package? Or will there come others?

Build tools and their config

Although the fetching and installing via a external dependency falls away, this does not mean it gets simpler. The build process often gets much more complex and harder to understand. In a polyrepo you have challanges with dependencies and their respective build system too, but it's simpler and easier to understand those systems.

Performance

For great projects with dozens lines of code performance becomes an real issue. Searching, fuzzy finding files, etc. will get slower with every line added and every file created. That's why big adapters like Google use custom tools and workflows to fulfil their work.

If your organization is subject to this, you will sooner or later need to solve this challenge.

Read about the benefits here

https://royalzsoftware.de/your-app-is-wasting-potential

Conclusion

A monorepo isn't a magic pill and comes with its own unique challenges.