I can see how performance might be a concern but I've never run up against issues with this in my own implementations using redux-form. Maybe if you do some exotic stuff it could be a problem, but yeah, never had an issue with this.
What I do love is the use of redux dev tooling -- for literally every action on my form, I have a log of when it occurred and how exactly it affected the state of the form. This is simply awesome. Yes, there are probably ways to do the same thing with a non-redux implementation, but if I'm already using redux I get this for free in the same tooling I already know and love.
For what it's worth, I have in the past (before understanding the tradeoffs of where redux state vs component state makes more sense and trying to do everything completely 'purely' in redux state) foolishly tried to keep all inputs and other UI components' state in the redux store, in a completely hand-written element id based mess. I totally agree with the sentiment that it's not necessary or worth the effort to manage one-off component state in redux in the general case.
However in this specific case, redux-form encapsulates and manages all of that complexity and you don't have to think about it at all. Actually ironically other than the redux dev tools part I don't really care about the 'in redux' part. I just like the library and its API.