For the billing system to then "turn off" X it needs a number of things.
1. It needs the ability to reach back out to that service. It probably has no idea what it is, all the billing system is likely to receive is something like:
{service_name: "X", action: "Put"}
So now your billing system needs to be able to resolve "X" back to some AWS resource that it can talk to. Both the resolution of X as well as the "billing can now talk to every single AWS service" are pretty heavy lifts.
2. It needs to know what "off" is. "Off" for S3 could mean a lot of things.
a) Delete the bucket and all data inside of it
b) Keep the bucket but delete all data inside of it
c) Keep the bucket and the data but disable API access
etc etc. Do you disable PUT? GET? Both? What if what's blowing up your billing is GET?
And this really doesn't get easier for other systems. Do you back up a database before killing it? That incurs charges too.
I don't see AWS somehow solving this in a "one size fits all" way because there isn't one.
It's not an engineering problem at all at its heart.
It's a marketing/business problem that someone somewhere is thinking that Amazon can provide a free service to X users, knowing that Y (X, Y positive, Y << X) users will go over their "free tier" usage and pay for all X's costs, maybe even more, making the free tier a profitable business on its own.
My point is that it is definitely an engineering problem as well as a product problem.
a) It's going to be super technically difficult to build (especially in a way where it's responsive at a granular basis to handle huge blow-up bursts)
b) It's not even clear what you're supposed to be building
None of what people are proposing is well defined or easy to build.