This is certainly not due to anything deliberate by the main contributors to core Gradle, but rather an issue of not realizing the side-effects of changes being made until much too late into the process. Unless it is core Gradle, there isn’t any coordinated testing being done on plugins currently (hopefully the Plugin Portal can help out with this eventually).
Core Gradle is great, but just like Jenkins, Ant and Maven, it is the 3rd party plugins that flesh out the entire workflow that users tend to need. Adoption of Gradle is growing rapidly, and it is clear many users require plugins beyond those distributed with the core.
If the bar for maintaining compatible 3rd party plugins with a rapidly advancing core rises too high, users find themselves forced to stick will older versions of Gradle out of necessity (which is not good for anyone). It also can deter new and existing plugin developers if they find themselves struggling to keep their plugin contributions functional.
Admittedly, some plugins need to reach into the internals of Gradle to accomplish their goals, and are most prone to breakage, but there currently is no automated feedback loop to the developers of the core (or the plugin writers) that helps to highlight the impacts of changes early so that designs can potentially be adjusted up-front to accommodate needs until some internals can be refactored into something that can be exposed in a more general way.
-Spencer