It's not that so much but that novice users see two ACLs: "Public" and "API Key I use to deploy." So it's very easy to "fix" an access issue by making a bucket public, with the alternative being to give your application the keys to the kingdom. This combined with S3's most frequent use as a file server means that buckets get opened up. You have to jump through hoops and dig into Amazon's access model for anything more nuanced, and only people experienced with AWS will understand or know how to do that.

Making a bucket public should come with red flags, and there should be a simpler way for client-side code to securely access a bucket. If I save a user's uploaded files to the filesystem, I usually have to go out of my way to expose that. Even novices are less likely to put them inside the web root, so exposing such files involves jumping through hoops. Opening a bucket to the world is too easy in AWS.

Calling this situation "insecure defaults" was imprecise of me, my point was more that Amazon gives you a Big Red Button to "fix" things which has consequences like this.

It does have red-flags. When you try to set a bucket to "public" in S3 it literally tells you: "This bucket will have public access. Everyone will have access to one or all of the following: list objects, write objects, read and write permissions."

I mean, there's a difference between being a novice and being stupid.

They were times when people used to manage their servers and they had to be careful on how to use 'rm -rf' or 'dd' tools.

I find it funny how today there have to be red flags, warning signs and double confirmations everywhere. Are people less competent or are there simply lower requirements when hiring them?

Not if you use aws-cli. But I think the larger issue is that Amazon doesn't provide a low-friction, secure way for applications to access their buckets. A good way would be for each bucket to come with its own access key, or expiring tokens that you could query on the backend and use from the browser. Just spitballing of course.