Update: I'm only talking about warnings coming out of use warnings. This stuff doesn't necessarily apply to warnings the programmer affirmatively generate (e.g. with warn, etc) and intend to go into a log file (or somewhere).

There are some concerns with warnings in production, and you should decide for yourself how these impact your situation. Like bracing style and other religious wars, arguing with developers over this means you aren't getting work done. Let the project manager decide then get on with life. :)

I'm not going to vote yay or nay. I'm just going to say to think about the consequences of either course of action and decide which one works for you.

0: People have to see the warnings. If no one is going to monitor the logs with all the warnings, you don't need the warnings. Also, if there are so many warnings that people will stop looking at the logs, then warnings can be bad. If no one is going to fix the warnings, then what's the point? This might sound stupid, but I've seen plenty of places that don't care about fixing warnings. Catching all warnings sounds good, but in reality people start to filter out the things that show up over and over again, or that annoy them. An ivory-towerish, dogmatic policy usually has unwanted real-life behavior adjustments.

1: You want to notice important messages. If the script outputs a lot of useless warnings, or the same warning repeated over and over, that's a lot of text to sort through to get to the warnings which might be more important. It's the old needle-in-a-haystack. That's the same for a script that outputs a couple of warnings but executes hundreds or thousands of times.

2: Warnings such as "Use of uninitialized..." aren't very helpful in log files. If you want to clean those up, you can turn on warnings for a bit, get the warnings, then turn them off again. You might even want to be able to turn on warnings externally (environment variables, etc) so you can decide to have them on or off without editing any files.

3: A script might start off warnings clean, but then through an upgrade to a third-party module or even perl itself, it all of a sudden isn't warnings clean. I've seen a couple of clients go down because their disk filled up in the middle of the night since warnings that weren't there before showed up all of a sudden. Despite any failings in deployment policy and so on, it can happen.

5: Turning off warnings to get a performance boost is probably just optimizing in the wrong place. If that's the main argument for turning off warnings, don't bother with the extra work. You don't want to edit files just to turn off warnings. Any change requires attention and monitoring.

6: Don't just turn things on or off without monitoring the script. No matter how harmless the change I just made, I usually find it's not so harmless. :)

Now, the goal is always to have warning-clean code, and, as you say, programmers should take responsibility for the warnings their code generates. At the same time, however, a really good test suite with good coverage should catch most of that. Beyond that, a way to replay a particular run (same user input, environment, etc) with warnings turned on should generate the warnings you would have seen for a particular problem.

I usually recommend that people leave existing scripts as they are and start any new policies with new work. If you have time, slowly fix old scripts. Don't try to fix them all at once lest they all break at the same time because you did something odd while editing them. Avoid spending too much time thinking about the past until you have to (that is, don't mess with what's working). Once you have to fix an old script, give it a general warnings clean up. You have to test the script for your new fix, so you have a chance to what warnings pop out and fix them at the same time.