> What "state" one needs to handle is app dependent. Some do need client-side interactivity and some don't. Obviously, if you need it, you need it. Saying "almost everyone doing front-end work has that problem" is something you'd have a hard time proving. Historically, most things people have built on the web have had relatively low levels of interactivity. There are brochure sites (read-only) and there are forms-over-data (read, with data entry) that both lend themselves well to a server-rendered approach.
As soon as you have any kind of interactive UI, either you do sever roundtrips for everything (which is usually unacceptably slow) or you have client-side state. Tabbed form section? State. Two-level dropdown? State. Radio button enabling different parts of your form? State.
Theoretically it's conceivable that someone might have a website that needed only flat forms with zero dynamism. But I've found that everyone thinks their website is like that, and they're always wrong. Every Rails/Django/Wicket/etc. site ends up needing one little piece of unmanaged JavaScript somewhere (unless you're lucky enough for a server roundtrip to be acceptable latency-wise). And then one more piece. And then you have a state management problem.
> My team maintains 30 or so Rails applications complete with collaborative two-way sync form entry and real-time (enough) commenting with server rendering and Rails. The first app we built used React. I can tell you with absolute certainty (because I've done it) that the React version is still more expensive to maintain, still the place that the devs prefer to work the least, still the most expensive to extend.
You must see that your experience is unusual - perhaps you're using React badly (understandable in a first app), or your team has spent more learning time on Rails. There are scenarios where Rails might beat React on a level playing field, but this shouldn't be one of them. Apart from anything else, how do you do handle the client-side state in the Rails case?
> HTML is what React renders. You need to write something like it when you write your JSX.
Right, just as your Ruby runs via a C interpreter that ultimately executes as machine code, is the analogy I was drawing. Having a bit of familiarity with C and your processor's assembly might be helpful for some kinds of debugging occasionally, but it probably shouldn't be a priority.
> Server-side rendering is necessary if you want anything resembling reasonable time-to-interactive
I assure you it isn't. In some use scenarios it might be, but I've worked on sites that were very fast without it.
> or SEO.
Perhaps - but not everyone needs SEO.
> Progressive enhancement is something every web developer has to at least be aware of when it comes to CSS.
It really isn't these days. Even a very inclusive baseline of browser support still gives you plenty to work with - e.g. flexbox is 12 years old at this point. It's entirely practical to set a reasonable baseline and just not do progressive enhancement (particularly since often the "worst" browser you're targeting - iOS Safari - is also the one that most of your customer base by value uses, so there's little to gain from progressive enhancement).