You're grouping wildly unlike things.
Backend for Frontend is one thing, frameworks that hoist frontend state to the server (LiveView, Blazor, etc.) are another.
And none of the benefits you're describing are tied to RSC or anything that OP was banging their head into. React Router offers loaders that run on the frontend and have largely the same ergonomics.
tRPC/oRPC also remove most of the ceremony around building an API while also skipping the downside of implicitly creating a loosely typed API for your frontend.
But then again, this isn't really that fruitful of a conversation. I think even by the tone of this comment I can tell you're bought in, and I'm not. People who aren't bought in are just looking for reasons to complain, people who are are busy building. Right?
Yes all their implementations are wildly different, however their motivation is the same: maintaining complex front end state and backend state and then syncing it via a manually defined API is too complex. That, combined with the problem of how do we solve SSR in such a way that minimizes complexity while still maximizing front-end reactivity.
Live view says "render it all on the server and then just constantly sync with an open connection". Now we have that reactivity, but we still have SSR AND we don't have to meticulously craft an API. Next says "render it on the server, or maybe the client, we'll figure it out and automap the data". Inertia says "okay kind of like next, but you have to define some stuff a little bit more. But we'll render react or vue on the server or client, too".
And, for the record, I hate next, and I think they're approaching it from the wrong direction. I think inertia makes more sense, and ultimately live view is the "end state" of this concept.