It's policy. Existing orgs get the option to disable it grandfathered in for one more release. New ones require opening a case. It may be more difficult to disable after Winter '17, so don't treat it as a permanent workaround.
As noted here
Availability
LockerService will be made available starting Summer ‘16 in the following manner:
- If the org is a brand-new Summer ‘16 org, or if the org has no Lightning components, the LockerService will be enabled automatically.
- If the org has at least one Lightning component, the LockerService will be made available as a Critical Update and the Admin will decide.
Important: LockerService will be auto-enabled for all orgs when Winter ‘17 is released in the October timeframe.
Also from the Release Notes:
If you don't see this critical update in your org, LockerService has been automatically enabled and can’t be disabled. Automatic enablement occurs within 24 hours after the release.
You can disable LockerService in a Developer Edition org created after the Summer ’16 release. We recommend that you test LockerService in a Developer Edition org to verify correct behavior of your components before enabling it in your production org.
Too much for a comment but important to note:
Right now, there is a lot of noise. Other than the general rule it is hard to tell what is a bug, user error, or not allowed. I believe this is a consideration with the recent notification that the Enablement of Locker service this summer can now be rolled back by the admin rather than being permanent using API versioning
Received on 4-28-2017
In Summer '16, we introduced LockerService as a Critical Update. We
planned to enable LockerService, including stricter Content Security
Policy (CSP) in all orgs, starting with Summer '17. However, based on
customer feedback, we have revised our rollout plan.
(Emphasis Mine)
With the revised rollout CSP has been decoupled from LockerService and
won't be enforced in production orgs in Summer '17, and now you have
the option disable LockerService by adjusting your API version.
LockerService Enforcement is Dependent on API Version LockerService is enabled for all Lightning components with API version
40.0 (the version for Summer '17) or higher. LockerService isn't enabled for components with API version 39.0 and lower, which covers
any component created before Summer '17.
To enable LockerService for a component, set the API version to 40.0.
You can disable LockerService for a component by setting the API
version to 39.0 or lower for the component.
Component versioning enables you to associate a component with an API
version. When you create a component, the default version is the
latest API version. In Developer Console, click Bundle Version
Settings in the right panel to set the component version.
Stricter CSP Restrictions Aren't Enforced Yet The stricter CSP restrictions, which mitigate the risk of cross-site scripting attacks,
have been decoupled from LockerService and aren't enforced in
production orgs in Summer '17. The stricter CSP changes are available
only in sandboxes and Developer Edition orgs and can be activated in
two new critical updates:
- Enable Stricter Content Security Policy for Lightning Components
- Enable Stricter Content Security Policy for Lightning Components in Communities This gives you more time to update your code to work
with stricter CSP.
Best Answer
In LWC, Lightning Locker is always enabled to enforce code isolation.
https://developer.salesforce.com/docs/component-library/documentation/lwc/lwc.security_locker_service
Are you facing an issue with Locker? We monitor these forums and try to address the concerns as they come up.