Eons ago, when I worked in the student lab for a bunch of VMS terminals, I'd ask the approaching student "What's the problem?" and often get "I'm getting all of these errors." Only a couple of times, I responded that "If the errors are the problem, then let's get rid of those" and then typed¹:

 $ set message/nofac/noid/nosev/notext
[download]

and walked away and waited for "That worked great. But now I can't get it to produce the output that I want."

It is my experience that most computer users don't appear to attempt to understand the error message they are given. Ever notice that many root nodes mention that errors are produced but don't actually say anything about the contents of those errors? Many nodes don't even mention the presense of errors despite it turning out that error messages were output. Many people don't bother to include $! in their own error messages (in large part, I believe, because many people don't attempt to understand the error reasons that $! provides).

Of course, many error messages are hard to understand. So eventually giving up at trying to understand error messages is not too surprising of a result.

People turn off "use strict" because they don't understand the "noise" (a telling word choice) that results.

So you have to help people learn how they are supposed to try to understand an error message. And sometimes you just have to help them understand the specific error message that is right in front of them.

For strict, I'd show them a simple example of mistyping a variable name and provide the two ways to "fix" the error: 1) correct the spelling of the variable name, 2) comment out use strict. If they actually pick (2), then show them that the program doesn't work. More likely, they pick (1) and then you can explain that the error message was helpfully pointing out a problem and that is the purpose of error messages. Then you can discuss how pointing out mistyped variable names doesn't work unless you declare every variable you use and skipping that step only makes sense for quick hacks.

But, yes, watching people ignore error messages can get frustrating. (:

Update: And in your particular case, I suggest getting "use strict" added to the company's coding standard practices so you can just leave as soon as you see it commented out.