I don't think the objective of Framer X is to output code. When they say "React, meet design", what I take that to mean is that the API is transitioning to one or many React Component(s) instead of plain Javascript classes. Meaning: When you use design tools to insert a rectangle onto an artboard, that Rectangle is a React.Component under the hood, perhaps passing all of the design-related attributes like width, height, x-pos, y-pos, etc — as props. They can also extend React.Component and potentially add methods for managing states/transitions that will better encapsulate certain sets of interactivity that we as designers would like to model. This also bodes well for reusability of components that we author.

Original Framer + Coffeescript requires a mostly imperative approach to the programming aspect of it. A key strength of React is that it is declarative, and each component's view reacts to changes in its props. Its difficult to appreciate how powerful this difference is until you've worked with both, but I can definitely see the potential in moving Framer to a React based API, and I'm very interested to see how they did it.