I don’t change my point (even if I understand the @dimaip comment).
React with tons of modules, based on our needs, sounds good, but I’m afraid of the nightmare to maintain those dependencies correctly and React + tons of libs will not be a lots lighter than Ember 2.0 
Yes moving to Ember 2.0 is a bit of a pain, but moving to any where else will also be a lots of pain. As we don’t use the Ember routing, an Ember component based apps, as a lots to share with the React alternative. Glimmer (the rendering of Ember) did a pretty good job (in term of performance and memory). The VirtualDOM is nice (and faster), but need higher memory usage, and for a really big UI apps, we need to take care of memory. If we target tablet, memory is a pain point.
The modularization can also be done in Ember. Ember CLI use NPM …
About the decoupling at the same time that the rewrite … I prefer to go step by step and dont push the decoupling too fast. Decoupling require a rock solid API, and creating this kind of API is pretty complex, and can depend on stuff like CQRS.