I think you just described one way of updating things on a web page. The paradigm which React uses is popular in this moment, but there are many other ways to update things on a web page. It does not actually do anything that couldn't be done before, or with other frameworks or libraries.
For me, tools that I find useful are ones that make something no longer be my problem as an application dev. For JQuery, it was low-level browser implementation details. Sure, browsers were different, I just didn't need to care anymore.
For React, it's "Calculating what are the DOM changes that need to happen to ensure the UI reflects the state of the world". In practice, this means that I no longer need to be concerned with "What's the current state of the UI", and I'm not manually diffing things. To a large extent, it makes client-side UI code look a lot more like server-side UI code.
State is one of those things that's a PITA to reason about -- the less of it that I need to care about, the easier it is for me to make code that works. Reasoning and testing in one dimension (space) is a whole lot easier than reasoning in two (space and time).
Using jQuery you can express a UI as a function from Application State to DOM? I'd be really interested in an example. I've only ever used jQuery to do lots of imperative-looking DOM state changes.
It is not common, easy, efficient or idiomatic, but you can:
Imagine that in each event handler, instead of doing something, you just update some state somewhere, and after that call a common "draw" function.
Inside the "draw" function you redraw all your UI: apply effects, etc.
That's it, you have it.
Along these lines, this is why Dan Abramov's Getting Started with Redux[1] is one of my favorite tutorials to anything, ever. The concepts are simple, and half the tutorial is walking through creating a naive implementation of Redux. The actual library, of course, involves performance optimizations and better edge case handling, but at the very least, having a "this is sort of what the innards look like" is a really nice start to approaching anything.
The end user doesn't know or care about implementation details. It's bikeshedding that nobody cares about except the developers themselves. Facebook could have built their web app with Angular or Ember or whatever and nobody would give a shit except developers. Even as a developer I don't give a shit about what framework a web app I'm using is made with as long as it works (if it's horribly broken then I know what to avoid).
Isn't that like saying I'm not an architect so I don't really care what kind of foundation my house is built on as long as it hasn't fallen down yet? They're all held up by the same laws of physics anyway.
