These are legitimate concerns to have. There are many new technologies at play in this space and a lot of new concepts.

> What really remains to be seen is whether this reduces or increases complexity.

One word: scoping

This is an important concept in software development that we've severely lacked on the web. We're used to creating global documents of HTML, CSS, and JS and hoping it doesn't explode. Frankly it's a mess. I'm surprised we've put up with it for so long! The technologies behind web components (Shadow DOM and Custom elements in particular) empower us web devs to be good developers. That is, we can take advantage of patterns like OOP: compartmentalize and scope functionality to a particular problem space.

CSS/DOM encapsulation is an added benefit to tell this story. As a developer, I no longer have to hunt down what CSS is effecting my page. I just look at the element's definition.

The hope with all of this stuff is that there's less re-inventing the wheel and more productivity. Scoping takes us to this happy place. Unlike most new web platform APIs, the web component APIs are purely about developer ergonomics. It's about your productivity. That makes me super happy...both as a web dev and someone who teaches web devs.

> Like Addy points out ("not a silver bullet") performance, security,...

Nothing in web development is a silver bullet :) A best practice today may be an anti-pattern tomorrow. However, with components, we have the opportunity to bake in more for free. For example, accessibility is low on people's radar. If a component set takes care of the details for me, I'm a happy camper.

Nothing changes in regards to security. In fact, the API specs leave it out entirely. When people hear "encapsulation", they automatically think security. IMO, it's better to think about components as "scopes".

> ...one of Polymer's example components was an Ajax call, which I suppose you can fire from the script. Is that really better than putting the ajax parameters in the code?

Web components allow us to rethink what HTML can be; what it can do. We have to unlearn years (possibly) decades of assuming that HTML can provide no useful API. When given a declarative vs imperative API, I suspect 9/10 developers will go the declarative route. It's unquestionably easier.

`<polymer-ajax>` is a good example of providing an a hybrid. It defines an imperative API on its DOM interface and a declarative one by configuring it through attributes and listening for events. Is the declarative route better? Perhaps. The point is that it encapsulates the details of using XHR. I'm excited to never NEVER write that boilerplate XHR code again.

Ajax is also a trivial example. The cognitive load of being a web developer is oftentimes too high. You can imagine more complex APIs and libraries (webrtc, webgl, etc) being offered as declarative custom elements. A declarative option makes those underlying technologies more convenient/approachable to others.

> Does it encourage "globals"-like behavior, where hidden dependencies crop up?

Components encourage the opposite. When used correctly, HTML Imports provides the necessary dependency management. If an element requires script x and element y, those deps can be included/bundled as an Import for the component.

> Are there life-cycle behaviors to the Ajax component that might trigger the request at surprising or frustrating times?

There's nothing stopping component authors from shooting themselves (or their users) in the foot. It's my hope that well-written components will surface to the top of the stack. If a component is naughty, no one will use it.