We tried to, and removed it within 4 weeks of development with it, for all of the reasons you mentioned. It conceptually doesn't map to our Redux model, and new developers struggled with it because of that. I ended up writing my own "wrapper" to do something similar, but to be honest for most of our form state it is handled within the components themselves (via this.state and friends) and only sent to Redux once validated. React's built-in state handling is still useful, specifically for these sorts of things.
https://github.com/studionone/ is where it will live, plan is to release it this week, all things going well.
What I want is a higher order component for a given form parent specified by a string, with higher order components for all common html5 form types which are stored in a state tree child node based on a string for the form parent and each component which encapsulates form elements, and rolls up small change events to avoid event log spam.
I originally thought a json or other dsl solution would be ideal, but that ends up being an integration and interoperability headache. Jsx as a dsl works better than json as a dsl for ui in my experience. The big question is where to store the "batched" changes before being rolled up.
I think rather than component setstate, perhaps a sub tree in the redux store with its own subtrees could exist with a specific prefix that could be hidden in the redux devtools chrome extension to avoid the spam problem. I rather like this solution, as it would make react and redux forms beat the simplicity of angular 1 forms with all the benefits react and redux bring. Would other people use it? Anything like it exist already? Maybe I'll create this...
A definite high point of my time with it was when a requirement came along to allow users to resume signup - because all the form state was in the Redux store already, it was simply a case of serializing that and putting it in localStorage (or wherever), then reloading it as the initialState.
There are performance issues to be aware of if your form gets too large, caused by the "top down re-render" effect of having the top level ReduxForm HOC connected to the form state and therefore re-rendering on every keystroke - often these can be solved by splitting the form into sub-components with appropriate shouldComponentUpdate etc., but this isn't a perfect solution - see https://github.com/erikras/redux-form/issues/123 for a lot of discussion. The new v6 API aims to solve this, by removing the need for a single top level component: https://github.com/erikras/redux-form/tree/v6
I've been intending to write up my experiences and how I've been working with it, but decided to hold off until the v6 API stabilised, so that I wasn't giving outdated advice. Happy to answer any questions in the meantime!
I've been using redux-form in large production app, btw, and have mostly found it nice, but am looking forward to migrating to the new version.
I question whether people use it in large scale production. This is one of the huge downfalls of redux. It makes some things easier, but it makes the most fundamental stuff (editing form fields) extremely contrived. This is the main reason I don't see react+redux as a true answer to the challenges of SPA development but a very rough, intermediate step which needs to be re-thought while putting into consideration the most common use cases.