This is a big question with a long answer :)
Probably the biggest reason, in my opinion, is the "weirdness budget" that the team referred to in their recent I/O talk. https://www.youtube.com/watch?v=7CUO7PyD5zA
To pickup Polymer—really, Web Components in general—requires grokking a number of concepts like how Shadow DOM does both DOM and CSS scoping, how Custom Elements need to have a unique name in the registry and therefore must be deduplicated across large apps, etc. Plus juggling all of the polyfills.
Taking all of those concepts in, as a new developer who just wants to build a thing, is a large ask.
In hindsight, I wish that Polymer had been a bit more opt-in. You could imagine a version that only uses Custom Elements (similar to what X-Tag did initially), and then optionally lets the developer add things like Shadow DOM if they want. This maybe would have made it easier for folks to onboard.
Another thing we realized was that folks really want help managing state in their application. We largely tried to avoid this issue early on because we believe web components can be used with any state management strategy. But I think that made other libraries, in particular React + Redux seem more compelling for folks.
But ultimately our goal is to make Web Components succeed. The Polymer team is part of the Chrome team and was created to help prove out those new standards. They've done some really amazing work and it's wild to look at where Web Components were 4 years ago and how much the specs have evolved. Seeing libraries like Angular and Stencil adopt them is, in our opinion, a huge win. I think that's ultimately what we'd like to see—other libraries adopting web components as a useful part of their story.
Reply to this…