I've been using Web Components entirely without Lit (and somewhat dislike Lit) both "Vanilla" and with a JSX framework that is not a Virtual DOM (not React).
I think WebComponents for me started to click when I realized that for the most part I don't need the Shadow DOM at all and can work entirely in the "Light" DOM.
The other thing that only more recently clicked for "vanilla" Web Components work was moving to implementing `handleEvent(e)` and relying on "old fashioned" event bubbling over endless `this.querySelector('#element_name').addEventListener(…)` (and `removeEventListener` if you are a good citizen and care about garbage collection) boiler plate.
The Shadow DOM makes sense if you need a more powerful `iframe`, but that's almost never what I want, because I trust CSS and trust the Cascade. So much of the Web Component API complexity is just and just for Shadow DOM. Web Components make so much more sense in the "Vanilla JS" world as soon as you realize you can YAGNI Shadow DOM and stick to the Light. I understand that for ad companies and "powerful embeds" companies really want a higher powered `iframe` and so I can't blame Shadow DOM for existing, but I can blame Shadow DOM for making Web Components look like frightening things that "need" Lit rather than simple things that Lit pretends are more complicated than they are because it also assumes you want to start from Shadow DOM by default rather than Light DOM by default.
(You don't get some of the automagic of the `template` tag if you eschew Shadow DOM, which is silly and "Light DOM template standards are still on the roadmap" but the `template` tag is still useful in Light DOM work, and ironically Lit doesn't make good use of the `template` tag anyway so even most Shadow DOM users are not using `template` much yet.)
Similarly, a lot of the "I need a framework like Lit" comes from event handling and it feels like a full circle of the jQuery days with lots of querySelector/querySelectorAll and addEventHandler/removeEventHandler imperative shuffles in connectedCallback and disconnectedCallback, but one of the things that created the situation that was jQuery event handler hell was people not learning and/or distrusting the event bubbling system and one of the performance tools (that even React uses under the hood) in the jQuery world became moving event handlers up the bubble chain and being smarter about fewer handlers (even as the jQuery "state of the art" never strayed very far from lots of very specific handlers). (In React's case this is why in the debugger you often see classes called SyntheticEvent and friends because React often subscribes at a higher bubble level and then creates synthetic events to make it look like you are creating event handlers lower in the DOM.) In the WebComponents world you can implement the `handleEvent(e)` in your (Light DOM) Web Component, get addEventHandler/removeEventHandler "for free" from the browser, rid yourself of a lot of query selectors, and take (performance) advantage of the event bubbling.
For the same reason that most jQuery era scripts still used very explicit query selection and on/off handlers and React uses synthetics to pretend to do low level event handling with bubbled event handlers there's a developer experience issue in building combined event bubble handlers versus "localized" event handlers to deal with, and that may still often lend to wanting a framework to support writing event callbacks as "localized" event handlers, but Lit isn't doing anything particularly interesting there either (it takes an approach somewhat like Angular, preferring localized handlers and just providing template sugar for addEventListener/removeEventListener). As far as I'm aware no one is really quite thinking of it in that way of bubbled handlers other than the easiest way to write Vanilla JS WebComponents, but I've been toying with my own "micro-framework" ideas there.