Software has to be monetized somehow. SUSE and RHEL and Oracle Linux are monetized by subscriptions to support contracts. Slackware is monetized by sales of double-sided DVDs. Ubuntu is monetized by a mix of support contracts and begging for donations on the download page. OpenBSD is monetized by a a mix of donations and merchandise sales (including install CD packs and t-shirts and such). I'm not one to believe that ElementaryOS is any more or less sinful than any of those examples.
My issue with the eOS team wasn't that they said "we want to make money for this", but that they accused their users of being cheats for not paying them for the software, the vast majority of which they didn't write or maintain. I want OSS devs making money. Heck, I want the eOS guys making money, if they're making a product that people like and want to see continued. But their tack was pretty amazingly hypocritical.
As a result I've had to run Elementary in a VM with snapshotting, and I roll back the snapshot if an update hoses the install. Kinda shitty, if you ask me.
And then you have NixOS, which - while not really mainstream yet - is probably a good indicator of the future of configuration and package management, and - I think - will someday be the gold standard here. Upgrade fucked up your system? No problem; just select your last-known-good configuration at boot, then try again (or don't try again, if that's your prerogative).
This sounds like a configuration that could potentially be applied to other Linux OS'es, no?
In practice, this tends to be a difficult problem to solve because most Linux environments are managed imperatively/procedurally rather than declaratively, meaning that in order to revert to a previous state, you have to be able to run the exact commands required to do so. The traditional answer is to manage such a system with Puppet or Chef - thus allowing an administrator to tell the system what it should look like rather than how it should go about it - but that's generally yet another layer of logical overhead to be considered.
NixOS - in theory, at least - addresses this more fully by integrating declarative configuration rather pervasively throughout the operating system itself, rather than trying to just add a layer on top of the operating system in order to manage it. It relies heavily on the Nix package manager - instead of installing a program directly to the filesystem hierarchy, it installs it to an isolated folder named with a theoretically-unique hash, allowing multiple versions of the same program to coexist without conflicting (and allowing users to pick which version they want), making it painless to roll back software upgrades (just go back to a different selection of which package folders should be linked to, rather than having to manually remove and revert each package), etc.; NixOS leverages this package management system for everything, rather than just the software installed, and will create GRUB entries whenever you commit your configuration changes (by running `nixos-rebuild switch` or `nixos-rebuild boot`, causing an instant configuration switch or a configuration switch on next boot, respectively).
Other operating systems can hypothetically do this, too, and they'd end up looking similar to NixOS in terms of how things are organized and configured. As I said, I think that's probably the direction where most operating systems will eventually go.
Time Machine on OS X works that way (as do a few other incremental backup solutions, I believe). Notably in Time Machine's case, it hacks a way to hardlink to entire directories which haven't changed, which is normally not possible. (There's a parallel here with how immutable data structures are managed.)
That being said, the more people on Elementary the better! I've grown to like Vala, and encourage devs to help contribute.