1. It is designed to be testable. It makes testing the components much easier than testing jQuery soup.
2. It has an opinionated way for developing javascript applications
3. Will validate input types passed to controllers
4. Has nicer syntax than jQuery soup
I'm not sure if you're blaming the tool or not, but at least for 3rd parties, I want to clarify: jQuery doesn't mandate "soup" - In fact, devs learned over time that the best approach development with jQuery was the same as without - have application state tracked as variable(s), have routines to translate the current state into the the DOM. That's the unidirectional flow that React likes, and both vanilla JS and jQuery can run with it.
But jQuery makes it EASY to use your DOM as state storage, which works well at first and quickly grows nastily complex. Meanwhile, React makes it EASY to update the DOM from state without performing unnecessary re-renderings.
So jQuery doesn't mandate, or even encourage "soup", but there's nothing guiding you away from it. React, OTOH, makes the path of least resistance be towards this particular best practice.
To your points as to why people use React, I don't think those are bad points, but those aren't my primary points. React best practices mimic the best practices of coding in general: Small, single-purpose components with minimal coupling. This allows me to bring in experience from outside React, and allows me to apply React experience outside of React.
1. It is designed to be testable. It makes testing the components much easier than testing jQuery soup. 2. It has an opinionated way for developing javascript applications 3. Will validate input types passed to controllers 4. Has nicer syntax than jQuery soup