First, standard disclaimer: Security is not an all or nothing proposition. Security procedures for an anonymous favorite-cat-voting website will not be as stringent as the security procedures for the nuclear football. You need to decide on a security level that property balances cost vs usability for your organization.
That being said, I agree with keithRozario's answer, and will give you a couple more reasons on top of his why I personally wouldn't rely on just the bucket name.
The public is not the only "group" to worry about
Many studies show that roughly half of all data breaches start internally. Even if the "public" never guesses your bucket name, that doesn't help if the group that is responsible for half of all data breaches (aka your employees) does know your bucket name. Like anything else, if it contains production data, it should only be accessible to employees who need access to production data. If you have a "secret" bucket name but embed it in your source code where everyone can see it, then it isn't really a secret, and you may in fact have problems in the future.
Access keys can be rotated, bucket names can't
In a comment you asked why a long bucket name was different from API access credentials. There is a very simple reason why they are in fact very different. If the employee in charge of your production systems leaves on bad terms, you can invalidate their access credentials, create new ones, and update your systems. However, it's not always as easy to change the name of your bucket.
It's like the difference between a building that has magnetic card entry vs a single master key. With magnetic card keys, if someone leaves, you just revoke their access. When everyone has a single master key then you have no choice but to change the locks and replace everyone's key when one person leaves, which in reality means that the locks never change. Relying on the bucket name for security is equivalent to giving out the master key to everyone who works for you. No thank you.