A coworker best describes the dillema we faced in making this decision:
"It’s a tradeoff of where we want the [error] to come from. Failing in a predictable way that leads to the solution vs. failing in a unpredictable (possibly destructive) way with no indication of how to fix it. I think we’ve made the right choice here."
Let me expand on this.
It is almost always the case, even when a high compatibility goal is in place, that software will diverge with each subsequent major version release as a result of innovation and bug fixes (security bug fixes are the most obvious here). These changes will invariably lead to (sometimes very subtle) breaking changes, both intentional (for example, security bug fixes) and unintentional. As a result, applications that worked correctly on one version of the runtime could malfunction (also in a very subtle way) when run on a later version.
This is precisely the motivation in eliminating the default roll-forward policy in the v4.0 release of the .NET framework. While we strive to make each version of the .NET Framework highly compatible with previous releases with the goal that the vast majority of applications will "just work", we still want authors to evaluate their applications on each release and explicitly opt into running on them.