That doesn't mean core have to stop to be revolutionary on some aspect but that new needs should be taken into account when deciding what to change, how fast and how.
...
If you change 3 different parts of the API in one round, porting modules will be a harder task than if you concentrate on making one part of the API really really nice so that it won't have to be touched soon. Changes will still be radical in terms of improvement but porting may become an easier task.
Please correct me if I understood you wrong, but I think you're arguing for backwards compatibility in Drupal's APIs. This has been discussed several times before and the arguments are still valid: Ensuring backwards compatibility would lead to unnecessary overhead in the source code and longer development cycles. For example, the new menu system in D6 forced module developers to re-write most of the code in hook_menu(). While I think that providing backwards compatibility basically would have been possible, the API is much cleaner without it. Upgrading a module to the new API is (for most modules) fairly easy, since all aspects are well documented. However - to continue this example - modules that were doing crazy things with an "old" API (like Drupal Administration Menu) have a hard time porting to D6. While backwards compatibility certainly would not help them in any way, I can clearly see a need for communicating major API changes in Drupal core to potentially affected (suffering?) module (maintainers) in contrib. For instance, the new database API currently in progress for D7 will break each and every module in the wild. That's good, since the new API will introduce great features and better compatibility with other databases. However, there might be modules in contrib that need support for advanced functionality (f.e. multilingual solutions, integration and migration modules) which should be taken into consideration while developing the new API. Daniel