ECN

There will always be one more thing that'd be nice to fix before a release, but you need to stop at some point if you want to make a release. If you are going to freeze things make releases, you can do worse than regular time based releases (since it gives a good indication of when features that miss the release will be made available).

In this case, a problem was identified with two possible solutions: disable the problem code or fix it. While in the long term disabling the code is the wrong solution, it must have been deemed to be the less risky choice in the context of the upcoming release (i.e. which change is less likely to introduce more bugs). So, the choice made is actually related to release quality.

You'll see the same sort of decisions made elsewhere, picking a low risk solution for the short term and a correct solution for the long term. For example, disabling the dynamic ftrace feature in the 2.6.27 series rather than merging a proper fix.