Sure, from a dev perspective the API may be bad. But I'm saying that that isn't the right perspective to use when judging it.
"Nice" APIs or higher level APIs are desirable of course, but they tend to be much bigger in size and scope, much more opinionated and brittle than a smaller low level API. A portable API which browser makers can accurately implement and support for the long term, is a smarter goal even if it does expect devs to build a "nice" layer on top of it first.
In case of WebComponents it could have a small sane layer on top that wouldn't be too large. See WebComponents vs Polymer: [1]
As it stands now, it's nigh unusable by developers. Almost no frameworks even use it as their foundation. And those that do compile to them go out of their way to never ever use it anywhere except in base classes, maybe: [2]
As a result, today, 9 years (!!!) after they were first proposed, the very person who proposed them relegates them to "webcomponents will be used incidentally not totally" [3]
"Nice" APIs or higher level APIs are desirable of course, but they tend to be much bigger in size and scope, much more opinionated and brittle than a smaller low level API. A portable API which browser makers can accurately implement and support for the long term, is a smarter goal even if it does expect devs to build a "nice" layer on top of it first.