If warnings can't be redirected to a accessible log file, next best thing is for the user to tell you about it.

I would need to work very hard to find a reason to turn off the warnings, regardless of where a program might be running.

I believe warnings should be fixed, not silenced. With that in mind, using -w is preferable since all warnings observed are bugs that need fixing. The bugs might be harder to detect without -w.

Warnings (and, to some extent, errors) are only as valuable as the communication channel that gets them back to the person who can fix the problem that they tell of. Displaying a warning in "production" is usually not just unprofessional looking but also very often nearly useless because the warnings displayed are very unlikely to get back to the person who can "fix" the warnings with enough fidelity to be much use.

For example, I don't "use warnings;" in my modules. I do, however, have "-w" on the #! line of the my t/*.t module test files. And I also use "-w" on the #! lines of the scripts that I personally use. This means that warnings are displayed when they will be displayed to me. They are also displayed when somebody tests my modules. So my code is well-tested as far as being unlikely to produce warnings.

But my code does not produce warnings by default when other people use it.

I would only enable warnings in production if I had already established the communication channel that gets the warnings faithfully back to me, which might also mean that the production users would not even see the warnings (if the "customers" of this production code were employees, they probably would; if they were external customers, they probably wouldn't).