In fact, the issuance of warnings might (well, not likely, but "might") cause my not-entirely-hypothetical idiot to actually read the prompt, once that's written in a manner which makes the required input explicit.

This largely depends on the user audience. Some Perl I write is customer-facing and warnings from the interpreter (be it Perl, Python, or extra debugging printf or println statements in C or Java) are very frowned upon when you're writing code customers will use. Techniques like defensive programming and encapsulating errors really does make a difference when you're writing well-designed, professional code. Granted not all projects require such attention and polishing, so perhaps this was what you were getting at.

I take a fairly strict approach to untrusted input in that it needs to be correctly validated, and I know my audience might not even care to read a line of Perl to use my program. Cluttering the screen of someone who may have simply made a typo with technical jargon (as much as it helps those of us who write Perl) does not increase usability if the error message is well-written, and in fact decreases usability by cluttering the screen with information not all users will be able to understand. If more direct description is required, the error message handling such bad input should be improved.