strict.pm has run-time as well as compile-time checks. For example, symbolic references can only be detected at run time.

I consider dereferencing a symbolic reference to be an indication of a pretty serious error (if you wrote and tested the code under 'use strict') that I'd want that flagged in production. I fully support turning off warnings in production (though I even more support keeping warnings turned on and providing a system for the warnings to get routed to the developers so they can be "fixed").

FWI, I can't think of any warnings that are controlled by strict.pm, but that doesn't mean there aren't any. (:

I still don't understand. Is there any case where strict merely produces a warning?

What I'm talking about is strict failing a program at run-time, and then dumping stuff in the logs, viz:

Global symbol "$foo" requires explicit package name at /home/user/www/test.pl line 10.

.. it's getting rid of that kind of stuff that I'm talking about (I don't think warnings makes any difference in that case?)

This is no reason to disable strictures, it is a reason to use CGI::Carp's carpout() or set_message() functions. Disabling strictures is a serious mistake especially on a production server where failing a stricture at runtime should be indicative of a critical bug. In such a case, you want strict to scream bloody murder and kill your script rather than the script being able to run on and silently throw sand into your machinery.

Makeshifts last the longest.