I kind of want to refer back to OP's question, because you're right, but in context it's a little confusing.

when people talk about state, they mean destructively mutable state... state doesn't abstract over this kind of mutable state, it abstracts over state that is modeled as plain old immutable data that gets passed around

Redux, the JavaScript state library in question, doesn't deal with destructively mutable state either. JS of course doesn't natively offer the sort of guarantees of immutability that Haskell does, so it's up to the programmer to ensure that Redux's state is always changed via pure reducer functions, not mutated. (Whether that's through following convention, introducing libraries like Immutable.js that enforce immutability, or a combination is up to the developer.)

Redux itself doesn't really care if you mutate its state - you're not supposed to, but it won't break anything. But Redux is usually used to manage state with the React view library, and React cares quite a lot about immutability, as parts of it rely upon referential equality to decide whether to update the view.

Very broadly speaking I guess you could say that React/Redux and the State monad are similar, in the sense that you could conceptually view a React/Redux program as a function AppState -> Input -> (AppState, View).

I'm a shitty Haskell developer, so please let me know if this is totally wrong... but I think the main difference between Redux and the State monad is level of abstraction. Redux is a relatively high-level library that orchestrates state management for an entire application, while the State monad can be a lower level abstraction, used to thread a second value through a functional pipeline, much more tightly scoped. So Redux is more like, I dunno, Yampa or another FRP library that handles the behind-the-scenes wiring for you so you can focus on business logic. Redux is far simpler than Yampa, but I think it's a morally fair comparison.