The vanilla way tends to result in state spread out throughout your JS and DOM. React UIs act like predictable functions: you describe the UI you want with your current state as the input and React makes the visible UI match that.
I think this is a JQuery problem, as it makes complexing state the path of least resistance. i.e. modifying the DOM directly instead of via functions. Resulting in code that is hard to test or debug. React seems to fix this, witch makes it a good argument on why to use it. My counterargument for "vanilla" JS/HTML is that you can refactor the bad parts. But you can't get rid of React, or you would have to rewrite your whole app! Like when the next JS fashion/framework comes. grin
React itself is just the view. You can replace your template language without redoing everything if you want. Khan Academy, for example, still has some Backbone views that render with React. We also have some Handlebars templates that we haven't converted over yet. That's all peacefully coexisting, though we'd love it if all of our views were React and more of our data handling was just pure functions.
But you CAN get rid of React and not have to rewrite your whole app. Redux, for example, isn't coupled with React at all. React-Redux gives you the tools you need to tie the two together, but you could easily take your Redux code (reducers, actions creators, selectors) with you to a new framework like Angular 2.
"Current state as the input" sounds like a big caveat. I'm having trouble distinguishing this from "you describe the UI you want with your current document as the input and jQuery/JS/whatevs makes the visible UI match that."
You also want to batch your DOM manipulations as much as possible, and you get it automatically by using vDOM libraries.