You can definitely run Uber-scale systems with <100 engineers. Whatsapp was famously run by like 30 people or something. The problem is when you expand your business at the rate Uber has, or any VC-funded startup, in which case you gain massive (absolutely massive) amounts of tech debt in the form of bandaging new features onto old code without proper refactoring. Then you start doing "microservices" and you hire 10k engineers and now you have even more problems, and your infrastructure and codebase expand exponentially.

I think for a good scaled architecture, the keys are: having at most ~30-50 developers, good planning by a few key architects, controlling what's in your database with an iron fist, knowing exactly which bits of data are where and what they are used for, and having strict codebase standards.

However, to really be successful in the goals above, the business needs to support a rigorous software process. Normally, this is where things fall apart, since business people and sales people (who are otherwise great people) will push you to work faster and cut corners to get things done. In the end, they also pay the bills, so if the business isn't run by people who understand why software development has to be strict, then you get sloppy software processes.