There's still a lot they could do around that though, e.g. requiring that billing details be re-entered upon change or sending an email alerting the user with instructions to secure the account if it was not authorized.

Just as likely as basic credential compromise is lateral attacks on compute resources from vulnerabilities such as Log4J.

Enabling MFA, restricting intra/inter-VPC access, removing hard-coding credentials from configuration files/source etc., switching to SSO/removing user accounts with passwords, creating and applying restricted IAM roles, and applying those reduced privileges to EC2/ECS/EKS instances are all things that and should be done as soon as possible. (Non-exhaustive, but illustrative list)

AWS could simply require the user verify they have access to the card or other payment method on file.

That is super impractical when you run 200 AWS accounts in production.

The option to set a limit doesn’t require you to set one. Assure lets users have a limit without any significant issues.

Does AWS require distinct billing accounts for each project? I use GCP, I can attach the same account to multiple projects. (It also lacks this basic billing limit feature, unfortunately.)

No, that's why it would be silly to have to change it for every account. (and also problematic for a team with a bunch of child accounts to then have to gain access to the org's card or something like that to change settings for their childs)

I don't follow. But they could make the quota feature a toggle (that has the same mechanic to unlock). Easy, easy enough for a junior dev. And I'm sure folks spending more than a few minutes chatting about it could come up with an even better solution.