The correct answer, as always, is to ask the customer.
Let's take a simplistic example and say you're paying per gigabyte. You decide you're willing to pay up to $X, and Amazon tells you ahead of time how much your $X will buy you, and you accept.
One type of customer will be using that storage to store priceless customer photos. Even if the customer ends up deleting the photos, it has to be your customer who makes that decision - not you, and not Amazon. You tell Amazon that you'd like an alarm at $X-$Y, but that if you hit $X, keep going, at least until you hit $X+$Z.
Another type of customer will be using it to store a cache copy (for quicker retrieval) of data backed up in a data warehouse somewhere. You tell Amazon that you'd like a policy which automatically deletes all the oldest data, to guarantee to stay under the limit.
Yet another type of customer would rather keep their old data and just return an error code to the user for stuffing too much new data into too little storage, so basically, guarantee to stay under the limit, and guarantee never to delete data.
You can't solve billing until you communicate with your customers and ask what they want.
And the "correct answer" sometimes leads you to realising "Hang on, I just asked the wrong question to the wrong people".
So lets for a moment assume you talked to a large cohort of customers, and found a bunch of "types" including those three you list and many many more (inevitably, at AWS's scale).
You then need to make some business decisions about which of those "types" are most important to you, and which are way less profitable to spend time addressing.
So of course you solve the big pain points for your customers spending tens or hundreds of thousands of dollars per month before you prioritise the customers worried abou going over a tens or hundreds of dollars a month budget.
What would that solution look like? It'd have ways for customers with hundreds or thousands of services (virtual servers, databases, storage, etc) to make all their own decisions about alarms, alerts, cost ceilings - and tools to let them decide how to respond to costs, how to manage their data availability, how to manage capacity, when to shut down services or limit scaling, what can and cannot be deleted from storage. It would also 100% need to allow for practically unbounded capacity/costs for customers who need that (Think AliExpress on their "Single's Day" event where they processed $1 billion in sales in 5 minutes.) All this would need - for the $100k+/month customers - to be machine drivable and automateable, with extensive monitoring and reliable alerting mechanisms - and the ability to build as much reliability and availability into the alerting/reporting/monitoring system and the automated provisioning and deprovisioning systems as each customer needs.
And at least to a first approximation - we've just invented 70% of the AWS ecosystem.
You might think Amazon don't cater to people who want hard $5 or $70 per month upper limits on their spending. You're _mostly_ right. There are many other people playing in that space, and it's _clearly_ not a high priority for Amazon to complete for the pennies a month available in the race-to-the-bottom webhosting that people like GoDaddy sell for $12/year.
The thing to think about is - "who does Amazon consider to be 'their customers'?". I think you'll find for the accounts spending 7 figures a year with AWS - billing _is_ "solved". The rest of us are on the loss-leader path (quite literally for the "free tier" accounts) - because Amazon only need to turn a few tenths or hundredths of a percent of "little accounts" into "their customers" for it all to work out as spectacularly profitably as it is doing right now.
"and it's _clearly_ not a high priority for Amazon to complete for the pennies a month available in the race-to-the-bottom webhosting that people like GoDaddy sell for $12/year."
Except that that's what this announcement is.
Which makes me think this may be AZON's fix to runaway billing - if you don't have the resources to pay for mistakes[1], stay in the per-month kiddie pool and don't play with the heavy machinery.
[1] I started to add, "or trust yourself not to make them", but that's silly, because mistakes will happen.
I'd guess it's more to scoop up mindshare and make getting started easier, which almost assuredly leads to future upsells. That developer who starts prototyping a project on AWS instead of DigitalOcean now might make them $$$$ they otherwise wouldn't have down the line when that person needs to scale and doesn't want the huge pain of switching providers.
I don't disagree with your details, but you're arguing in a circle (here and in another similar comment).
Let's assume, based on the evidence at hand, that Amazon is rolling out Amazon Lightsail, and that as such, they're willing to do work (create business plans and write software) to court the $5/month market. In that case, it's a relevant comment for people to write "I can afford $5/month, or even $20, but I can't afford unlimited liability, even with what I know about AWS customer service, so I cannot use this product." It's relevant because it suggests that there's anxiety that is preventing uptake, which can be solved by a combination of writing software and internally committing themselves to eat the loss if the software is imperfect (as others have said, stopping service actually-on-time is actually harder than it sounds, but the provider can always just eat the loss, invisibly to the seller).
Your (probably-correct) observation that Amazon doesn't really care about the penny-ante user's money (in the short term) is beside the point.
Let's take a simplistic example and say you're paying per gigabyte. You decide you're willing to pay up to $X, and Amazon tells you ahead of time how much your $X will buy you, and you accept.
One type of customer will be using that storage to store priceless customer photos. Even if the customer ends up deleting the photos, it has to be your customer who makes that decision - not you, and not Amazon. You tell Amazon that you'd like an alarm at $X-$Y, but that if you hit $X, keep going, at least until you hit $X+$Z.
Another type of customer will be using it to store a cache copy (for quicker retrieval) of data backed up in a data warehouse somewhere. You tell Amazon that you'd like a policy which automatically deletes all the oldest data, to guarantee to stay under the limit.
Yet another type of customer would rather keep their old data and just return an error code to the user for stuffing too much new data into too little storage, so basically, guarantee to stay under the limit, and guarantee never to delete data.
You can't solve billing until you communicate with your customers and ask what they want.