The point being made is that web components can pay this cost per-component, and this problem will compound over time. This is an unprecendented cost to frontend framworks and it's the expected usage pattern.
On the other hand, if a component is small and focused in scope, it's likely either written in vanilla JS (like https://shoelace.style/), or made for a single framework (like the average React infinite scroll component).
In other words, I don't think you're wrong, but I do think you're prematurely optimizing a problem that doesn't really exist in reality. And the cost is big: if you get your way, every component author needs to either lock themselves into a single framework's users, or make 7-8 different versions of their component. I'd argue that that's much more wasteful than a few kb extra framework JS.
And then each component will have the entirety of that framework packaged with it when you distribute them. Unless you take special care
I did see one very badly configured app pull in six copies of Lit once because their bundler wasn't deduping, but: 1) that's still less than a React, and 2) an `npm dedupe` run fixed it.