One of the attractions of React is, or was I suppose, that it wasn't a full stack solution, but a UI framework. A lot of my work has been using React with whatever datastore and data source was most appropriate to the situation at the time (most recently, apollo-graphql, which is rather nifty, but also flux + some random API) rather than being tied to one blessed solution.
I'm not entirely sure if that's what they're discussing here, though. It feels like some hybrid mockery of server-side rendering and API/datastore, which makes me worry about possible merging of concerns and a loss of flexibility.
I feel like the real problem they're trying to solve isn't actually architectural. As far as React is concerned, the UI framework is a solved problem, with only incremental tweaking to keep up with standards from here on. Maintenance isn't nearly as glamorous or intellectually stimulating as new feature implementation, so they're inventing new features to creep towards. Server-side is the most obvious, but it's also a solved problem, using existing bundlers and compilers, like Webpack and Babel. This new server component system won't simplify things, because it will still have to rely on either implementation in an existing server-side framework such as Express, or on existing bundler/compiler toolchains, or it will have to become a complete replacement for all of them at some level.
But then, the javascript ecosystem is never one you could accuse of not re-inventing the wheel every five minutes...
The issue is ultimately one of "not invented here". They want to control the entire stack for their own purposes, rather than thinking about the community as a whole. React as a UI framework is great. React as a complete stack becomes overly complicated (yes, you can laugh here), unwieldy, prone to greater error, and isolated from the greater JS ecosystem. That kind of sucks.