It's overly verbose and error prone. Try adding an observable attribute. Then add another one. Then do something simple like change the name of the first one.
The Web Component APIs don't aim to be easy to use by application developers. That is simply not a goal of the spec. They're low level APIs which expose behavour and hooks on which libraries and frameworks can be built. As an application developer you are supposed to use those friendly libraries.
Aaand that's the problem with the API. The question was, how is API atrocious. Once an answer is received, it's immediately diverted to "the API is not for devs, you have to use libraries".
This doesn't make the API any less atrocious. And it would be nice if the platform didn't rely on libraries to make it usable.
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]
You can't just say "React" though, you have to show how it actually integrates with the DOM that we have. "Throw away the DOM we have" isn't a realistic option either.
