It will be interesting to see how it plays out. I think monolithic apps with server-side rendering are exceedingly easy to build, test, and maintain. Having a split front-end/back-end adds so much complexity and teams rarely take the time and care needed to make them work as well as server-rendered. Think about all the apps you use that are built this way - they are always more flaky, slower to render, and harder to use than if they were built conventionally. You have to actually take steps to explicitly make the back button work! and a million more things. You also see newer stacks return to server-side rendering as well.
That said, at a certain size, a team might well need to be organized this way, and I think Rails makes a great back-end API-only solution. My previously company had tons of microservices using Rails and I think Rails is great for that!
Where Rails is not great is as a so-called monorepo where your front-end and back-end exist in the same place with the front-end managed by the Javascript bundler of the day. Rails point-of-view is definitely not to do that so it doesn’t make it easy. Rails’ answer to dynamic front-ends is Turbo and while it might be great tech, it’s certainly not where the rest of the industry is headed, so time will tell how much adoption that gets.
If I could wave a magic wand, I would probably rather see Rails figure out how to use the industry-adopted front-end tools better and not diverge from them. Webpacker was a good try, but it is very painful to use and doesn’t work well enough to be as slick as the rest of Rails. Is there a better way to leverage React (server-rendered, client-active) in some sort of “rails way”? I dont’ know, but that seems more promising to me.