What? The only thing changing here is a default configuration value that actually gives users and administrators more control. This isn't like iOS or Windows RT, where you have to download an exploit and void your warranty to install software from a third-party source.
If I want to distribute an extension that users want but Google won't allow, such as a pornography browsing extension (disallowed by the CWS policies [1]), there's a HUGE change from an end user's viewpoint. I am FORCED to host it elsewhere.
Installing an extension from the CWS is as simple as clicking the CWS Install button and accepting the security/permissions warning. Currently, installing an extension from a third-party site is as simple as clicking the site's Install button and accepting the security and permissions warnings. To the end user, these are practically the same experience, and only one extension method must be learned.
After this change, the end user will have to learn that extensions are powered by files, that only .crx files are extensions, that a .crx file must be downloaded to install an extension (but only manually if the extension is hosted somewhere other than the CWS), and that they must drag-and-drop a previously downloaded .crx file to a Google Chrome or Chromium tab that has a specific settings page open.
This is confusing, and necessitates that a user learn two different workflows to accomplish the same task from different sources. This turns non-CWS extensions into second-class citizens, and it's not as simple as enabling inline installation [2] if your extension would go against Google's policies.
I don't know that drag and drop will work either. I am working in Canary right now and the drag and drop raises the exact same denial message as the off site install.
Yes, it may be not evil like WindowsRT and iOS and it may improve the security of users. But it's another brick in the wall being erected between 3rd party developers and users.
