In the systems I've designed, I've built multiple layers of protection around sensitive buckets. I figure it's safest to assume that someone will eventually screw up the policy.
When possible, I deny access to the bucket except for explicit whitelisted approvals (alternatively, requests coming from IAM roles or users in the current account).
I also encrypt buckets by default and often deny unencrypted uploads. The concept of public access doesn't map in quite the same way to customer-managed KMS keys, so you have good odds that S3 requests would fail on decryption even when a bucket becomes public.
Next layer of protection is monitoring via Config rules and Trusted Advisor checks, combined with alarms to ensure that these alerts are actually brought to someone's attention.
Finally, except for development accounts, I insist on automating configuration of the environment (and aim to use IAM to prevent manual changes).
This is great if you can pull it off, but you don't get there overnight. And you certainly don't get here by relying only on the basic documentation. I would say you don't even necessarily get there by relying on AWS partners. I've seen more than a couple disappoint.
All of this to say that I'm happy to add one more guardrail (with much lower overhead).