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.
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.