That does happen, it's just usually not when the card expires, but when the follow up billing emails get ignored for some period.

This is one of the reasons people have suggested using a different provider for backups.

You can already do any of those things in your own code when making the API requests. The issue here is, if you unintentionally try to make a billion expensive requests or allow someone else to do it against your account, do you want them to automatically turn off your stuff or do you want the bill that comes if they don't?

You're oversimplifying the problem in the other direction. Fine-grained scriptability of hard limits would bump up against all of the thorny distributed systems problems. But I do agree that fixing the simple cases is straightforward - maximum spend rates per instant and per unit of time (eg per minute, hour, day, month). Providers would shoulder the small costs from the slightly-leaky assumptions they have to make to implement those limits, and users can then operate within that framework to optimize what they want on a best-effort basis (eg a script that responds within a minute to explicitly scale resources, or a human-in-the-loop notification cycle over the course of hours so that you have the possibility to say "actually this is popularity traffic that I really do want to pay for, etc).

Funny enough, the utility business broadly wants to move away from this model to more of a cap-based prepaid model. Where I live, to get on the standard payment system may require a quite hefty deposit up front, but the prepaid payment option does not. I get the impression that, if not for customer sentiment and inertia, this would be the default option.