Hey Chris! To jump right into your main question:
proceed with just flow + redux or keep immutable?
There’s absolutely no problem with using Flow and Redux only. In fact, that’s what I use currently in a fairly complex e-commerce application. But one important thing to consider is that you won’t have the same guarantees with Flow as you do with Immutable.
You’re right when you mention that Immutable only enforces immutability at runtime. Flow, on the other hand, does static type checking at a compile time, and it does a great job at that too. But Flow does not guarantee immutability.
I think there are lots of teams and projects that can get away with “immutability by convention”. In fact, I believe most do. I must confess I have been bitten a couple of times by bugs caused by an inadvertent mutation of a data structure (my fault, obviously ).
The main reason my team decided to move away from Immutable on the front-end is that it was quite a heavyweight library. If page load time is important for your project, you might want to take that into consideration too.
Another point is that some members of our team slightly miss uses immutable, things like toJS(). Proptypes are also not sticked to often, I feel that flow can solve both those issues.
That can be a little concerning regarding the adoption of Flow. In order to allow incremental adoption, Flow is quite permissive with type coverage. And even if you enforce coverage, I found it’s easy to misuse Flow too (either by lack of understanding or malice). My advice would be to make sure everyone on your team understands the benefits and are fully invested in using the type checker. Otherwise, you’ll might end up with no type checking and a mess of a code base.
I hope that helps!