If you start with the premise that code should be warnings-clean in the first place, then it only seems logical to leave warnings on in production code -- because any warning that appears then indicates either (a) a real problem or (b) something that apparently works, but was overlooked when the code was declared to be warnings-clean. Case (b), despite not being an outright failure, is certainly unanticipated, and may indicate oversights in the design or spec. Either way, I'd prefer to know rather than ignore it. (And if you don't want your users seeing it, you can of course trap the warnings and send them to an application log file or some such.)

Secondarily, I tend to believe that changing as few things as possible between "pre-production" and "production" code is generally smart. It's hard enough to debug problems on code running in an alien environment when the code is bit-for-bit identical to what you're running in your dev or test environment. Why add another variable to the equation if you don't have to. (I know, simply removing 'use warnings' shouldn't cause any problems, but since I don't see much benefit to removing it, why take the chance.)