From my perspective, Atrix-like scaling up is an illusory solution - the engineering work to make it work properly is more than that required to make the cloud work properly, and the latter is better in the long run.

I suppose I need to justify that the cloud is better. It seems like a chicken and egg problem to me: people don't expect all of their data to persist between devices, so most apps (for mobile and desktop platforms) either don't integrate cloud sync, or do it in a haphazard way that requires effort to set up and is usually buggy and/or limited. Because most apps don't integrate cloud sync, people's expectations are set low enough that they don't demand it to work...

And this applies twice over for power users. In part because they're just likely to use more applications and more obscure applications in general, straying further from the beaten path and encountering wilder terrain. In part because they tend to use the command line, and command line interfaces are very portable, which means people still use decades old software practically unmodified, which is great in itself but ensures that it will never be possible to break expectations (e.g. file accesses might take time, and might not succeed) and expect most programs to eventually be updated to adjust to the new expectations. Not even over the span of a decade.

But for heaven's sake, NFS is 30 years old and allowed you to access all your files from any client. It's also completely unsuitable for today's mobile networks (or really anything other than a perfectly reliable wired link), but we've learned a thing or two about syncing protocols since then. Dropbox does a
reasonable job at the protocol level, and works so-so with the command line, but is a centralized service (I think an ideal one would be decentralized) and doesn't aim high enough (you only sync one directory, and some applications use Dropbox-specific APIs to get smarter syncing functionality; it's not integrated deeply into a whole operating system). iCloud (+ Continuity) has the right idea in general, but is also centralized, and not (yet) sufficiently pervasive.

If this is so hard, why not just do the Atrix thing for now? -- Because while that can maybe be an okay solution with some more work, it's only a good solution if apps seamlessly switch interfaces when you dock or undock. Which is in practice is probably going to look very similar to cloud sync (data being transferred between separate applications), just on a single device.

There's the conservation-of-CPUs aspect, but I don't see a single CPU being suitable anytime soon for both maximum speed (when plugged in) and low power (when not). At best you arrive at a compromise that's not ideal for either. And do you really want a laptop dock that's a brick without a phone (i.e. if you leave the phone at a different location, or if you want one person to be able to use the phone while the other uses the laptop), if including a CPU and some minimal storage (enough to get what you need from the cloud...) would not be that much relative increase in price?

Do you really want to hold fast to a world where losing or damaging a device that you take with you everywhere can cause the loss of important data? I found the Google's goofy "people in lab coats destroy Chromebooks in amusing ways" ads (conveying the concept that no data is lost) pretty compelling; too bad Chromebooks are so limited even today.

There's the NSA angle, but the fact that most of today's consumer cloud services do not include client-side encryption and/or are closed source is hardly inevitable or unfixable.

There's the offline experience, but "cloud" can always be a protocol that can operate totally standalone on a LAN if necessary, adding the Internet as a communications channel when available. (Certainly today's cloud services could do better with LAN optimizations - if my phone and laptop are on the same Wi-Fi network, I should never have to wait for the Internet to get content from one on the other. Actually, this is true if they are close together, period. Use Wi-Fi Direct if you have to.)