As someone leading a team that does releases to clients, this is a pretty naive take.
As you scale you get quite a few constraints that require additional manpower
1. Scaling generally means revenue, which means more internal teams pumping out more business products/features.
Those features often need some sort of mobile integration. So you not only have your planned features, you have the features other teams would like you to work on.
The larger the company, the more requests like this you get. Feature velocity MATTERS.
2. As you scale you almost always have to rework your backend to some extent to keep up with load/feature growth. This means existing features are at risk of using deprecated & older APIs/Tools and need attention in order to keep working and allow scaling.
3. By the time you're scaling into the millions, you're almost certainly acquiring enterprise users. You can skate by in the individual/small/medium business with some pretty glaring bugs (things like 2% of all android users see crashes at startup). This wiggle rooms goes away when you start working with enterprise customers (or at least gets considerably tighter). It's an inconvenience when your 15 person org has that one phone that doesn't work right. It's a showstopper when the 10,000 seat org has 600+ users who can't use the product.
Those are just a few of the differences that happen at scale.
----
Long story short, you're not really wrong from a technical side - A small dev team can absolutely make a small & focused app and manage to scale.
You're just glossing over the politics of working in an org that's successfully scaling.
It turns out being able to get additional employees that don't need extensive mobile experience and can just crank out features is a huge pressure release. It lets that original tiny dev team (the folks who could write a fine native app without any issue) focus on bigger/harder problems.