I kind of feel that given the "simplicity" of a single class wrapping custom elements, everything is pretty boring.
Note: I cannot do better.
I think FAST is dead because MS doesn't want to play keep-up with it. In fact, all of the component libraries that Lit advertises on their home page (https://lit.dev) seem be Thanksgiving leftovers put out on a buffet. No one is seriously updating a set of web components for public use.
But... perhaps that is because Lit isn't really great for making components for others? It doesn't get you out of the work of documenting them, for example, which is already done with canned component libraries. It certainly puts all the fixes back on you.
In my experience, Lit is terrific for green sheet projects and ones where you can keep everything in-house. But there is no "Lit community" or resources for people getting into it who want a jump start. And no great tutorial doc.
Unsurprisingly, you don't see Lit discussed too much anywhere!
I don't use lit-element, it's too heavy for me.
lit-html, on the other hand, is wonderful and rock solid.
I typically do light dom components, rendered with lit-html. Simple classes that extend HTMLElement.
When I want reactive style, I add setters that call render(). When I want imperative, I add class functions.
All my components generally take care of themselves and are mostly encapsulated, they'll generally have a init() method that loads the data they need, and calls a setter which kicks off the render cycle.
Alternately, data will be passed from a parent component via a property, and that'll also kick off the render cycle.
In many cases I do a combination of the two in order to support deep linking.
I'll mix and match design systems sometimes, depending on the payload weight. Ionic, shoelace, etc...
The Vaadin router ties everything together beautifully.
I also have a small state utility called ApplicationState[1] that I use for the edge case of cross-component communication and triggering. It provides a graph-based approach to notifications/state change.
I've been using this approach for several years with success, with deeply complex and large applications and small lightweight tiny footprint apps.