If it helps at all, I develop software that runs on embedded systems like printers and factory robots. We develop in C, rather than Perl, but we not only have all build-time warnings turned up to maximum, but we won't accept any production code in which any warning occurs, for the same reasons as are mentioned above. We leave those on at all times, although the ASSERT macro does get commented out for release systems, but only because some of the tests take appreciable amounts of time.

For our systems as well as for Perl, having a log of user activity -- especially of any warnings generated -- is essential when bugs or problems occur. It's almost impossible to fix a bug if you can't reproduce it, and a good set of warning messages will let you do so. You may also want to dump your errors or warnings to a file rather than to the display, if a 'flawless' look is required for the user interface. On newer systems, we sometimes make the log file a rotating log -- it only retains the last 10 minutes' warnings (or whatever), but that's just to make it easier to manage a large volume of data. You shouldn't need that feature in a working system.