The problem is that it doesn't scale complexity-wise. You miss a key point with imports: A `<link>` imports something into the global scope. There's always one global scope. In my example, I was able to rename Toolbar into MyToolbar and use it in my scope. You lose so much using the DOM as primitive and JS as artifact.
And the second you start doing conditional elements (like the tabbed example), Web Components gets pretty complex. In React, it's just `if(shown) { renderItem(); }`.
If you make HTML smart enough, sure, you don't have to manually wire up anything. But then you're left with `x-if`, `x-ajax`, and so on tags. Why not just use JavaScript?
Using JavaScript is fine for things that need script, but ultimately, if I'm building HTML, I'd rather do it in HTML. Put another way: HTML is a great DSL for creating HTML.
As for scoping of imports, you do have a point there in theory, but in dealing with quite a few complex Polymer applications at this point I haven't seen that be an issue in practice. The scoping issue is well known among the people working on Web Components, and AFIAK there are plans to address it.
I'm not sure why you think conditionals are complex in templates. Your example might look like this in a Polymer template:
Yes, there's some token overhead, but in the context of a larger template it pays off to have the entire HTML specified in one place, and in a way that mirrors it's output structure, not spread out over often hard to follow imperative code.
However, as you point out, Web Components doesn't prescribe how to manipulate the DOM, so if you still prefer to do it in script, go ahead!
The point is to produce an element where the browser, developer tools, and your users don't have to care what choice you made.
When you start to bolt on features for dynamism in HTML you end up with Angular. The reason that it has all of those complex features is because it needs them to build real world apps. I'm sure once people have built more stuff with Polymer you'll start to see similar "feature creep".
I've worked with a number of very complex Polymer applications, probably the most complex Polymer applications in existence right now, and the template features have been sufficient so far, and there's always the fallback to code if necessary.
I can think of very few common feature requests (mostly on Shadow DOM, actually), and they don't being to approach the complexity of Angular, which concerns itself with so much more than templating. Angular's complexity is not simply an unavoidable consequence of being used for real world apps - it's just complex.
In practice you'd be namespacing your tags, so it'd be things like <polymer-ajax>, <google-slider>, <facebook-like-button>, etc. At scale you want this, as reading the code becomes quite confusing when you rename each component to your own custom name. It does make typing them out quite a pain (as anyone who's worked with YUI or Google Closure can attest), but that's the price you pay for large-scale development.
We reinvent C-style prefixes-as-fake-namespaces in HTML tag names when we have a perfectly good Turing-complete language with actual scoping rules sitting right here?
I don't mean to evangelize Polymer here - I don't actually have a horse in this race, having recently left Google and being still undecided about which technology my startup will be based upon. I think that the prefixes-as-fake-namespaces approach sucks, but of all the things you can get wrong with your web framework, it sucks a lot less than many other things framework authors do. And it enables the abstraction of "Treat web components like any other HTML tag, except you get to define their object model", which is a really powerful concept, particularly when you consider the possibilities of building the most popular of them into the browser. The problem with all existing JS libraries so far is that they become obsolete as browser technology advances; Web Components is the first one where the components may become the browser technology advances.
To complete your C analogy - yes, C sucks a lot, and it's woefully incomplete in areas like namespacing and packaging. But people still use C, because if you want to do something native it's basically the only choice, and you know that it will interoperate with basically every other language out there. And those people have managed to build some pretty impressive things with C, warts and all, even though a lot of its design choices "will never work" when programming at scale.
There's a really good chance that we'll get scoping for element registration at some point, given that the shadow trees are natural scoping boundaries.
And the second you start doing conditional elements (like the tabbed example), Web Components gets pretty complex. In React, it's just `if(shown) { renderItem(); }`.
If you make HTML smart enough, sure, you don't have to manually wire up anything. But then you're left with `x-if`, `x-ajax`, and so on tags. Why not just use JavaScript?