35-ish years ago there was a pitch for cheap, high velocity, spin-stabilized rockets that were deployed in dense pods on the A-10. The rocket's seeker could divert some small amount of thrust at an angle for guidance, but otherwise that was it. I can't recall if it ever made it out of the pilot phase, but obviously nothing new under the sun.
There are other mitigations though: You can pass expected owner accountId on S3 operations and you can create SCPs that restrict the ability of roles to write to buckets outside the account. Unless you have an account that does many cross-account S3 writes, the latter is a simple tool to prevent exfiltration. Well, simple assuming that you're already set up with an Organization and can manage SCPs.
[0] https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket...
Having worked in this space for years, it's not nearly as bad as you think. IaC tools can all look up the accountId/region for the current execution context and you can use SSM Parameters to give you a helpful alias in your code.
Also, if you have a bunch of accounts, it's far easier for troubleshooting that the accountId is in the name: "I can't access bucket 'foo'" vs. "I can't access bucket 'foo-12345678901'"