Drupal core release management: Exceptions to the feature freeze?

With the current release strategy for Drupal core, there is little that can change to a major release once it is published as a stable release.
Even worse: The feature freeze for D7 is now one year ago, and we still don't have a beta.
In some issues we can read things like "Too late. Let's clean this mess up in D8.".

Can we afford to work with a core that is already outdated the day it is published? Is there no way out?

The feature freeze has very good reasons:
- More energy is left for bugfixing.
- We don't break the API for existing code.
- Bugfix work is not hampered by neverending code changes and restructuring.
- We want to keep a linear progress between major versions.

So, yes, feature freeze is a good idea, and we should stick with it, as far as the above points are concerned.

But: One thing that usually will cause very little damage is adding new hooks. Contrib is doing it every day.
What can go wrong?
- Name clashes. It would be nice to find some conventions that can effectively reserve a hook namespace for Drupal core. But probably we have to wait for D8 with PHP namespaces. Still, it seems the practical relevance of nameclashes is not as severe as one would think: In all the bug reports I've seen I can't remember one that was caused by a hook nameclash.
- Future compatibility: A module that uses the new hook could break another module that assumed this piece of Drupal would remain static and unflexible. Now in fact it's not the hook that caused the problem, but the module that implements the hook.

It can't be much worse than new hooks in contrib.

What would we gain?
- People don't have to wait for a future major release (D8) to see some itching problems being solved, even before the currently developed one (D7) has a beta.
- We can react to real-world requirements by contrib authors, and don't need to guess all the flex points that module authors will need.
- We can start with a more static api, and introduce flex points (hooks) when there is a significant demand.
- We can introduce alternatives to crowded hooks like hook_init().
- If we notice that a specific part of core causes problems or limitations, but we don't want to change it due to a feature freeze, we can introduce a hook that allows to swap the problematic part of core with a contrib replacement.
- We have more time to brainstorm and discuss, because the new hook does not have to be published before feature freeze.
- The feedback from real-world usage of backported hooks can be used to improve the respective structure in the next major release.
- Contrib code can be a lot cleaner, with some dedicated and well-placed hooks in core.

In some cases we are already doing this (I think), but it is not a documented part of Drupal's release management. In most cases when someone asks for a new hook, the answer is "feature freeze".