Imo the biggest issue with this functional model (at least in React), is that it handles things like virtualization, async, etc. poorly. Which is kinda ironic, because in a true functional language, it'd be feasible to provide 'a world model' - that is act as if the entire state is always available, and let the engine decide when to evaluate pieces of code - without any effort from the part of the programmer.
Unfortunately when complex state transitions, async, and virtualization enters the discussion, the magic of React breaks, and you have to deal with all that, and also deal with how React's engine handles things under the hood.
Stuff like virtualization (if we're talking about stuff like virtualized lists) is hard not because of React, but because there just isn't any support for it in browsers. React doesn't really help here, but in my experience, it's usually the browser that starts choking on high element counts, not React.
Async is just difficult in general though. It's not really a surprise that most libraries/frameworks converged on similar designs.
I am talking about virtualized lists. And it should be a framework feature. I used to use WPF on desktop, and it had pretty good virtualization support (though the framework in general was more like Angular) - most containers had virtualization support, and you only had to implement the logic on the data source, and they framework created and managed physical UI elements for you, and managed the mapping so it seemed seamless to the user.
React also operates on a virtual dom, there's no reason imo why couldn't they just fake that for you.
I mean, it's not quite that easy. The web is a lot more dynamic than WPF. If you just want virtualized homogeneous lists, there are libraries for that (and grids).
But, once you start hitting things like differently sized elements, search and so on, you start running into platform limitations that you won't be able to resolve in React land.
I know, that's why I said, that when you hit things like that (state that is too big to pull onto the client at once, and/or displayed at once), React's (and I guess a lot of other immutablity-based frameworks') dataflow management stops being magic, and you have to start tending to it.
Which usually means this model loses all advantages compared to simple MVC, or imperative systems, and at worst, becomes another headache as implementation details start leaking.
I guess my point was that it doesn't matter whether your framework/library is immutable/mutable/retained/functional/MVC/MVVM or whatever. You're hitting platform limitations one way or another.
But the rest of your app still gets the simplicity of a declarative programming model.
Imo that's a rather nihilistic take. My personal opinion is that despite ungodly amount of money invested, the web has changed very little from the 'static website +maybe jQuery' days - 90% of the content people consume is static, with very little interactivity, that would be perfectly captured by the 'script' nature of Javascript (think 10 line scripts, like 'if hovered, play live preview of video'). Even that interactivity is mostly driven by data that needs to be fetched from the server.
'Web Apps' are the exception, and are more or less completely alien to the rest of the content, think 'flash games' or 'google maps' - which have become 'wasm games on unity on itch.io'.
Having a mostly static web for the former, and the ability to basically almost whatever would be for the best.
Speaking of Flash, the 'cross section' of the two - websites with tons of interactivity and flashy animation have almost disappeared.
The web of today is an unhappy compromise of mediocrity and low expectations.
Unfortunately when complex state transitions, async, and virtualization enters the discussion, the magic of React breaks, and you have to deal with all that, and also deal with how React's engine handles things under the hood.