Server rendered HTML is all well and good until you want to add native apps or a first class API layer. At that point, it makes more sense to have the web be just another client and move as much business logic into the API layer as possible.
Rails makes it easy.
Having a flexible API tier makes that more ergonomic.
The point is that the data model (and hence, the API design) applies equally to a web UI or a native application. The issues you're raising also matter for making webpages fast. When you think about the data model design before you make the presentation layer, in almost all cases, the choice of what you render is basically a straightforward transformation.
Well, someone did. The person above them said you can just map your Rails html routes into JSON returning routes (translating pages into API endpoints).
Which obviously gives you a suboptimal API since data access is tied to Rails pages instead of having a flexible, deliberate API.
And once you build and have to maintain the latter along with the former, you are now duplicating work. It's a familiar issue for people who have built SSR apps.
That was me. And no, you misunderstood. I said "controller logic" -- Rails (and any other decent web framework) allows you to map routes to endpoints in the code. In the simplest case, that endpoint could be used for an API response or a webpage, and just render different things. Alternatively, you can even have API routes mapped to a slightly different top-level endpoint, which does the vast majority of its work by calling the same set of downstream methods as the webpage version. Or a thousand other variations on the theme.
In short, assuming that you don't just structure your code as one gigantic function for each route, it's not hard to do, or hard to maintain. You do have to think a little bit about how the controller logic fits in with the API and the webpage structure, and I contend that this is the actual, practical reason that we've seen so much burdensome (over)use of React, GraphQL and the like -- those things are separate teams at many companies, and the "decoupling" theoretically unblocks the teams.
Maybe with graphql it is different
This is not 2011 when every website was building an "app" for native experience. If you are not building an Uber or an AirBB, you will probably manage.
Those that want it easy, use Electron.