I’m afraid this “right way” you are proposing, even if it makes sense in some case where, as example, you couldn’t extend native
<tr> or similar elements, seems to miss the most important point: accessibility, a word never mentioned in your entire “everyone else is doing it wrong” analysis.
input or a
button inside a custom elements, gives you tons of accessibility for free:
tabindex, events that will bubble up automatically as trusted, and so on.
On top of that, Shadow DOM is one of those parts of the specifications very hard to reliably polyfill, and an architect should know a robust foundation is more important than some strawberry on top, isn’t it?
And indeed Custom Elements have been reliably polyfilled for many years: Google AMP, A-Frame, Stencil.js, these are just a few projects out there based on the most widely deployed and compatible Custom Elements polyfill, which is another missing point in this whole post.
The whole built-ins extend part is also missing here, but it shipped long time ago with V0, fully embracing the original WebComponents intent you mentioned: extends HTML, not replace it.
Instead, due V1 inconsistencies brought in by WebKit team, we need to wrap built-ins if we want to be pragmatic and preserve accessibility.
Shadow DOM is also mostly unnecessary, unless you write code consumable by third parts, which is not always the case (or we’d had millions of UI libraries out there, right?)
Anyway, don’t get me wrong: some example you’ve shown surely does not make sense and looks more like an anti-pattern, but saying in Arpil 2018 everyone else is doing wrong, when specifications, polyfilled since 2014, has been explored and used in production way before Shadow DOM went out, looks a bit over the line.