You can have reactive programming with batch state updates. For the longest time, most React code used setState to update the entirety of a component's state at once rather than set each property individually and hope the framework batches up changes fast (or you use manual state update limitation logic like debounces). These days, I see a lot of React code having switched to functional components that suffer from rapid state updates, possibly without the authors even knowing.
In theory, these state updates shouldn't be a problem as your rendering logic and your state logic should be separate, at most rendering one or two frames wrong if the state updates are inconsistent. Video games have done this for over a decade and every "modern" GUI framework uses a GPU surface to paint its own controls rather than use existing system windowing, so you may as well take a page out of games' book.
Sadly, I don't think many frameworks do this stuff right and a lot of time is spend doing unnecessary state recalculations. It's certainly easier to write bug free GUI code through reactive programming, as state conflict bugs now get gracefully handled by the frameworks, but I think because these issues are now no longer clearly visible they also don't get recognised as bugs anymore.
I think this is just one of the many ways development has shifted towards developer comfort over user experience; changing a number in a region in memory and redrawing a string doesn't need to go through 50 chained method calls to update application state, but they make life for the devs easier so they're often tolerated. You get more features in return, but I'm not happy with the price we paid for those (mostly useless) features.