I'm not entirely against the idea that Run All Tests should be optional. After all, its no skin of salesforce.com's back if someone deploys a broken update that fubar's their organization's business process and causes endless delays.

The fact is, though, that once step 11 is reached, there is a problem with usability and stability, and adoption of the CRM is likely to fall. Often, sometimes a seemingly innocuous update will cause such severe damage that, without a testing phase, would cause problems later.

As an actual, live example, one of our developers added a validation rule to our project. One. Single. Validation. Rule. Now, you'd like to think that everything would have been all fine and dandy. After all, no code at all was changed. Unfortunately, it actually caused 78 test failures during the pre-upload Run All Tests. Had this validation rule gone into effect in a customer's database without any warning, they would have immediately lost about 25% of the total functionality of our package, and that 25% covered about 80% of what makes our package useful.

So, while I agree that it would be nice to skip the tests altogether, especially for seemingly small updates, salesforce.com has decided instead to mitigate the risk of lost productivity from a botched update instead of making it easier for developers to deploy lousy code.

Personally, I applaud their brazen attempt to make developers produce better code. Not many companies would choose to go that route, and I believe, in the end, that developers that regularly develop on Force.com will have better programming practices in general, even if they move on to another field of programming (such as PHP or C++). Someone should make a study on that subject.

And, your analogy on Linux is comparing apples to oranges. A Linux user is like a salesforce.com record, and a Linux package is like Apex Code. So, when you modify records in salesforce.com, it doesn't Run All Tests, just like Linux doesn't do any strenuous testing when a user is added. But, when you install a package in Linux, it runs a test, a version dependency, runs pre-install triggers, modifies the system, runs post-install triggers, cleans up other packages, etc. Linux and salesforce.com are very much alike in design in that regard. Even a Microsoft Update creates a restore point so you can roll back a failed update.

So, while it seems like overkill, I feel like they've almost got it right... you are correct in saying that the system should isolate tests to just suspect items, but that truth is actually reasonably obscure when you consider how everything ties together. Even the "security scanner" takes 6 hours to fully map a decent size project for flaws. Imagine having to go through that period for each "major" upgrade at the savings of having shorter "minor" updates. I don't think the trade-off would be fair.