Could you run with --profile against both milestone-5 and milestone-6, and verify that the increased time is due to dependency resolution? Also, the report might have some clues, for example a particular configuration or project has gotten much slower than it used to be.

Also, what do your repository definitions look like? eg Are you using Maven or Ivy repositories? Which protocols? etc.

Tested this with --profile against m5 and m6. m6 was in fact ten times slower but after some analysis, I separated the idea task from the assemble task and ran both with --profile again.
The assemble task got faster with m6, mostly the when resolving dependencies.
So the culprit is definitely the idea plugin - execution got a bit slower with m6 but dependency resolution ("all dependencies") jumped from 1m40.47s to 24m56.99s, across all projects and configurations (of course, runtime needs longer but this was also the case with m5).

We use maven repositories exclusively (plus a local flat directory), currently maven central, Apache, java.net, JBoss public (http://repository.jboss.org/nexus/content/groups/public-jboss/), guice-maven (http://guice-maven.googlecode.com/svn/trunk) and Scala tools release (http://scala-tools.org/repo-releases), all except apache via http. However, this doesn't seem to be a problem since dependency resolution is fast in 'assemble'.

Up-front explanation: Our current model of compile time dependencies (in fact IDEA's) is that library dependencies are transitive (i.e. if a project P depends on library A which in turn depends on library B, B is also added as dependency to P) while project dependencies are not (i.e. if P depends on X which depends on Y, P does not auto-depend on Y). Since we cannot set compile to transitive=false (and still get transitive library dependencies, see GRADLE-900) we add project dependencies with transitive=false. This has the problem that they're also non-transitive in runtime scope, which should not be the case (for us), so I wrote a "hack" to add all compile/testCompile project dependencies transitively to the runtime/testRuntime scope.
When deleting this piece of code, the idea task is still slower than with m5 but not that much (>2x: from 2m34.82s to 5m55.031s), re-enabling it lets the build time of the idea task jump to 26m29.46s.
Am I doing something completely wrong? If so, why did it work (and perform) with m5? Or is it just the time the idea task needs to resolve these transitives?
Maybe re-classify Component to idea but OTOH it's the dependency resolution that needs so long.

the "add transitively to (test)runtime scope" code looks like (called in aJavaProject.afterEvaluate with Configuration c, Project p, String targetCfgName):

pDeps=c.dependencies.withType(org.gradle.api.artifacts.ProjectDependency.class)
pDeps.each { d->
  p.dependencies.add(targetCfgName, project(d.dependencyProject.path), { transitive=true })
}

Confirming this works, IDEA project files build faster than ever! Thanks for the good work.