"use strict" is used in production all the time. Google and Facebook use it. The Babel transpiler (formerly 6to5) adds it to your code by default.
It's one thing to get JS programmers to write their code in a certain way, but if the VM knows they are doing so, it's even more powerful.
I guess the question is, how much better can you do, over easy-to-optimize code. Or in other words, once something is valid in Strong Mode, how much do extra Strong Mode optimizations get you.
Such code should already be quite fast in current JS engines. The big, big difference is between the engine getting hard-to-optimize vs easy-to-optimize code. So I would bet that the bigger deal is the devtool aspect here. But, these are empirical questions.
We lint, unit-test and acceptance-test aggressively (including legacy browsers), and the strict directive itself is of course scoped to our own IIFE. Perhaps that explains why I've not witnessed the hurt you mention.
The mechanics of strict mode are very clearly defined too, so I've not seen any cases were developer confusion caused unwanted side-effect (although I have heard straw-man arguments made where people predict it would).
The benefits, on the other hand, are real and tangible. Errors that might otherwise be difficult to diagnose fail hard and obviously. Browsers are better able to optimise strict code than non-strict. And culturally, I suspect that a use-strict policy has forced everyone to be more clinical in their approach.
Hand on heart, I would never go back to deploying non-strict code, so would be really interested to hear from anyone else in the opposite camp.
> I found two opinions about using strict mode in production:
> > There is no reason to ship “use strict” in your production code. There is no performance gain (verified with V8 team and Brendan a while ago) and I don’t need my users’ VMs doing the extra checks as well. Keep it development only, strip it out during build. This way you also avoid the concatenation issue you reference.
> > There may not be a performance gain, but there’s also not a performance loss. In production, even more than in development, is where you want to be sure you’re noticing errors. Minimizing the changes between the development and production versions of the code is key to being able to debug issues quickly and efficiently. Yes it helps during development, but there’s no reason to pull it out of production code.
> The source is in the comments at the bottom 
> And of course those 12b weight of "use strict" won't change a thing.
There have also been breakage issues. "use strict" changes semantics. Before all browsers implemented "use strict", some had it and some didn't, which meant scripts with "use strict" ran differently in different browsers.
That said, these days it's invaluable. Getting errors early saves time and prevents subtle bugs. It's become a widely accepted best practice, as noted by other posters.
I definitely share your concerns about mode switches, but as long as there's a conformant implementation to test against, it seems like strong mode could move the language forward without too much of the "use strict" early adoption pain. Strict mode wasn't completely smooth sailing, but I think in the long run it helped.
This issue bit Amazon in the ass a while back and gave rise to JSHint checking for function-level strict mode declarations only and the general rule-of-thumb to not use strict mode in production code.
Not changing JS semantics would avoid this. All the developer benefits are still possible without semantic changes.
Similar problems could easily arise in JS with e-commerce type applications, failing is sometimes a good thing.