HTML Custom Elements would allow you to define and provide support for your own <table-of-contents> element, so you could use it, and all browsers would understand it, and dev tools and CSS and JavaScript and all other HTML would work fine with it.
All that can be done without semantics. But HTML is also a document-oriented semantic language. Your way would just have idiosyncratic elements, which is little different than a div from the perspective of the rest of the world.
I think what you're calling "my way" is just what HTML is designed to be in its own specification. Custom elements have been in the spec for over a decade and are supported everywhere, they're as legit as any other part of standard HTML.
To descriptively move the needle on the semantics of custom elements you must first move the world. Any semantics you attach to your custom elements really is just your semantics. If you want this to change then start persuading everyone that your custom elements ought be semantically observed.
Until then, a custom element is just a div. Semantically opaque.
When we have actual consensus on elements and semantics, that enables very rich clients that can provide an alternative view over the same information, regardless of prior styling. For example, imagine if hovering over any time element will also show you a visual ticking clock or calendar. We wouldn't be able to do that if we didn't have consensus on the semantic meaning of time as something more than a valid token for a parser.
>HTML
>JavaScript
> in a sensible industry, would each be a dedicated field.
I get that webdev is a maze of frameworks, but that's just ridiculous.