Simple components are taken care of, but I think that's not where the discussion is very relevant.
I'm sorry to disagree here, but I think it's disingenuous to act like the problem is solved when there's really quite a large gap.
(Btw, of course I built my components with pure LiveView when it made sense.)
Depending on what you're building you could also say: "I want to spend time building my business, not writing an API for myself just so I can communicate with my own backend." Which is not even to mention how much simpler concurrency features are. But again, it depends on the application.
To be clear, I heartily endorse LiveView. Not using it now due to pretty heavy chrome extension needs, but it was solid. It's just rough in the "just works JS integrations" department. I'd argue you have to be really good at JS to handle any heavier library integrations.
You aren't wrong there! LiveView was initially developed to make a certain class of web-app without needing JS. Of course, people went and pushed it further and I see it as a "only write the JS that is necessary" type of framework. I'm very fullstack-minded so this doesn't bother me in the least. I love writing JS for DOM manipulations and whatnot, I just don't want to write any business or server-side logic with it, so LiveView is a great fit for me. But even as an advocate, if your application needs to be very JS-heavy, I wouldn't necessarily recommend it. No frameworks are one-size-fits all, but of course most people want to work that way.