Use one (and yes, only one) atom to store the state.
From my experience with React(Native) in the last ~6 years, keeping all the app state in one atom is a good thing.
I don’t use React context or any frameworks or patterns like FRP. I just pass props down from the root. All data management is simple, and easy to reason about. That way you avoid state inconsistencies and hard-to-reason-about bugs. I almost never run into performance issues.
If you do get performance issues, selectively add a useState hook to a component that is being updated multiple times per second. That’s when I run into the bugs and “what the hell” moments. It’s almost inevitable with multiple source of truth, and it gets exponentially worse the more sources of truth I add.
I believe concurrent mode is trying to solve a problem that a very big app might have. Dozens/hundreds of components, all developed by separate teams, where each component is doing its own state management and they want to avoid any and all state centralization (think the FB website, not even the mobile app, because there’s only so much visible on the screen in any one moment on mobile). If your app is not of this size, I’m not sure if you’d see a benefit.
One thing that CLJS does have going for itself is efficient immutable data structures. When you're using plain JS, you have to choose to use immutability. It's not the default. You get a situation where you have 10 teams working on the same frontend app, some are using Immutable.js and doing efficient rendering, some are using plain JS arrays/objects and re-rendering everything on any and every change. It’s a mess.
Concurrent mode might help a case like that.