> is it reasonable to consider react when you just want to add some interactions and dynamism to a page that was rendered server side?
This is more or less what I've been using it for at work. My general "rule" is that if I've got a form and any other field or set of fields depends on what's happening in another field or set of fields I try wrap both parts up into a React component (with as many subcomponents as necessary). I'm using react-rails[1] and creating custom form builder modules which I include in my main form builder class. The custom form builder methods just call react_component and pass in the form object as a property to the component so I get server-side rendering of the component and the same code gets reused client-side. Obviously it can be used for much more than dynamic forms, but for what I'm currently doing this is all I need.
> React seems kind of like an all-or-nothing approach. It seems like overkill if you just want to provide a little more structure to jQuery spaghetti code.
I've found that > 90% of my front-end bugs around forms involve fields that are somehow linked. Handling that with unstructured jQuery goes from easy to a horrible mess at a nearly exponential rate as the number of interacting parts increases linearly. React makes it really easy to keep track of state and have it flow downwards as properties to subcomponents. Obviously you can go way overboard with it and I wouldn't recommend it for everything, but the ability to use it in just one troublesome spot and nowhere else if that's all you need is really cool. It's the opposite of all-or-nothing. I have a very large application that uses it in about a dozen tricky places like dynamic lists of things. The rest of the application is just plain old server-side rendered HTML.
1. https://github.com/reactjs/react-rails