From https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0052.html

Annevk: " We're not sure about closed shadow DOM.
With composition/layout you want scripts to be able to go in and out.
(See also event retargeting.) For styling we'd like to see something
better than boundary-piercing. Ideally something akin to
pseudo-elements, but with the ability to put restrictions on the
amount of things they can affect. In Gecko we'll probably experiment
with "closed" in a way similar to Chrome (to get rid of XBL), but
unless we'd go down the isolated shadow DOM route (which seems
unlikely due to the overhead) that will require proprietary technology
that browsers are nowhere near ready to converge on."

FYI. I've added an API to create a closed shadow tree. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144#c17.

There, the default is "open" tentatively.
However, I'm aware that which the default should be is still in the discussion.

The resolution is: 
  "Will have both open and closed in v1, must be explicitly declared"

See https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting

Let me close this bug. See bug 20144 for the actual API.

Don't make it impossible for scripts to access nodes in or distributed in a shadow tree. Why? What if we want to have privileged chrome code modify or read content from a page, to alter or enhance a page's behaviour? What if we want to programmatically interact with nodes within a shadow boundary? If scripts have no access to these... this is impossible. It is essentially a form of DRM for any content on the web. The workaround is to recompile Chrome from source and revert changes that introduce these restrictions, in effect forking the browser.