Joern,
I'm sorry for your disappointment. You're not alone and we hear you. But I do think that a lot of the concerns you mentioned come from a slight misalignment of exactly what _has_ changed from Polymer 2.x to 3.0, and what has been _perceived_ to change from Polymer 2.x to 3.0.
First of all Web Components have not changed at all. They are an HTML standard and don't change when Polymer does. This means that all APIs for defining and consuming Web Components are 100% exactly the same as they were before. And the Web Components APIs have always been JavaScript centric for defining Custom Elements - from extending HTMLElement, to the lifecycle callbacks, to customElements.define(). And the APIs for consuming Custom Elements are the same, whether via markup, or script.
I understand that a lot of people were drawn to Polymer because of the HTML format, but Polymer has primarily been focused on enabling the easy authoring and consumption of Web Components and that remains the focus. HTML Imports were dead in the water and we had to move to a natively supported format so we didn't require polyfills indefinitely even on browsers that were natively implementing Web Components.
Second, Polymer has always been a nearly 100% JavaScript-based library. We've had people say they liked Polymer because it was HTML-based, but Polymer's HTML only contained <script> tags.
Third, Elements defined with Polymer have always been a combination of JavaScript and HTML. In Polymer 2.x, those languages were both put in an .html file, and in Polymer 3.0, they're put in a .js file. But the individual lines of code, and the division between HTML and JavaScript, are again nearly 100% identical - they're just in a different order. Even in Polymer 2.x you had to write plenty of script, including the critical script that defined and registered your elements. Only the templates were actually HTML.
Polymer 3.0 and all the 3.0 elements were automatically generated from their 2.x counterparts. They are that similar.
Lastly, we hope the situation where you have to define elements in .js files is only temporary. We're working on a successor to HTML Imports that integrates cleanly with JS modules called HTML Modules. You can follow the standards issue here: https://github.com/w3c/webcomponents/issues/645 and there will be more updates soon.
When that's in place you're be able to choose what file type you want to author components in, and consumers can in turn choose what file type they'll import your component into.
Again though, I want to emphasize that not much has changed besides the file extensions. I hope if you hang on there you'll get a fully native development target that supports authoring templates in "real" HTML like you want.
Hope that helps a bit. Cheers,
Justin