Rate limiting is infrastructure work. It requires deciding on appropriate limits, implementing a counter store (usually Redis), and testing the behavior under load. Developers building features under deadline pressure defer it. Then the API launches without it, and the deferral becomes permanent.
When an API is designed, the mental model is human users clicking buttons at human speeds. An attacker with a script can send thousands of requests per second. The gap between "designed for" and "actually receivable" is enormous. No limit means the API must handle whatever rate an attacker chooses to send.
The mobile app only lets you search for 20 results at a time. The web interface has pagination. But the API the app calls — the one an attacker calls directly — has no such constraints. The UI limits only apply to users who use the UI. The API itself accepts any parameters.
APIs that worked fine in testing — where a QA team ran normal usage patterns — collapse under attacker-scale load because the load was never part of the threat model. The API was designed to serve users; it was never designed to defend against bulk consumption.