Yes exactly, this is one of the lessons we learned early on. The polymer team have build a bunch of elements that actually represent services or models. Their philosophy is that
everything can be a web component.
We experimented with this a bit, but quickly found this to be rather worthless, it effectively means you have changed the location of your services from the Javascript namespace to the DOM.
I'm not saying that's terrible, just that it does not have any clear advantage to me, and a clear disadvantage would be that your services have to be accessed through the dom using for example element.getElementById() instead of just accessing them as they are defined on window or however the angular people do it with their fancy dependency injections.
That said, we do pull of some nice tricks that involve a bit of logic through combining components, and we do use web components as controllers. It is a bit like old school ASP.net code behind, but I like it.
edit: I have to be fair, I just remembered the advantage they aim for. When your services and models are also webcomponents, then you can make your dependency on them explicit using html imports, which would be the HTML5 solution for the problem RequireJS solves.