AWS is evidently not using their own tools correctly to build AWS then, because we know that the contents of security policies can easily contain sensitive information.
Just because Amazon tells people not to put sensitive information in a security policy, doesn't mean a security policy can't or shouldn't contain sensitive information. It more likely means Amazon failed to properly implement security policies (since they CAN contain sensitive information), and gives their guidance as an excuse/workaround. The proper move would be to properly implement security policies such that the access is as limited as expected, because again, security policies can contain sensitive information.
An analogy would be a car manufacturer that tells owners to not put anything in the car they don't want exploded. "But they said don't do it!" -- Obviously this is still unreasonable: A reasonable person would expect their car to not explode things inside it, just like a reasonable person would expect their cloud provider to treat customer security policies as sensitive data. Don't believe me here? Call up a sample of randomly-selected companies and ask for a copy of their security policies.
This is key to understand here: What Amazon says is best security given their existing decisions is not the best security for a cloud provider to provide customers. We're discussing the latter: Not security given a tool, but security of the tool itself, and the decisions that went into designing the tool. It's certainly not the case that the tool is perfect and can't be improved, and it's not a given that the tool is even good.