Sure it adds complexity, but isn't that what abstractions are for? We are talking about grokking how data flows in _a web app in Rails_. I wouldn't think usual workflow requires going into actual inner workings of React :p
The more stuff you add on the harder everything is to understand, and the less stable your app becomes until suddenly you need specialists for every piece just to keep things chugging forward. Everything needs greasing and maintenance over time..
..and then in 4 years the React team decides "oh you know what the way Svelte is doing things is actually way better.. we'll need a re-write to integrate their ideas". Now what?
"that wouldn't happen! so many businesses depend on React!".. uh they have no obligation to make things compatible with whatever you've built. They're not working for you. What happened with AngularJS? Vue 2?
Hotwire is easy to understand (React "just renders it" is a massive oversimplification)
If Hotwire rewrites? I create a private fork and continue on. Who cares
If I want to tweak how Hotwire works cause it'll benefit my app specifically? I do it myself
I'm not against adding complexity.. but if you care at all about longevity and long-term productivity then adding React really needs a tonne more consideration than it gets
But maybe I'm biased because I've been working with React for a long time, I don't find it too daunting to manage dev tools around React. When React was young, I remember that there were _a lot_ of ecosystem churn but now it's more-or-less settled and I don't think it's too bad.
I don't know how Hotwire works that well as most of my experience is around Elixir's LiveView, but at least for LiveView, there is also quite a bit going on under the hood to make it performant for large lists and to handle error states gracefully. And I (maybe incorrectly) assume Hotwire is similar, so I feel like it may not be not as simple as you say. (Edit: it is simpler than React though!)
Of course, you don't have to know any of that to grasp how to bang a page together with today's web frameworks; but you end up with the resource-hogging unmaintainable security disaster that is the modern web in the process.
Like, sure it helps in some contexts, but in their context it would largely be irrelevant.
For the wast majority of people, it's fine for them to know basic tradeoffs between stdlib container types. Most web performance problems today come from misusing tools, whether container types, bad algorithms, memory leaks (and I don't think knowing how an OS manages memory would help them in JS for example), DOM pollution, or oversized assets or whatever. And my take is that that people are often too overworked to care about it, rather than lacking awareness about these things lol
On the other hand, if you're a systems engineer, then you absolutely do needs to know all of this stuff.
And I bet you they'd navigate stuff like better than a systems engineer, because that's more useful to their day to day!
Experience of similar tradeoffs tells us it will only get worse over time, and LLM-generated web programming will make the whole process get even worse even faster.