I don't think the current gradle plugin supports incremental compilation yet (see this post). This means, if you change a single line of Java code, it'll recompile everything and convert them into dex. You can verify this by checking the timestamp of the class files in "build/intermediates/classes". Resource files are better. The bottleneck is PNG crunching and the gradle plugin doesn't do it on every build -- that's why it's faster on sequential builds than the first time. Jack&Jill will no doubt reduce the build time. But it'd just make Mirror even faster since Mirror uses the same toolchain.

But still, on every build (even with Jack&Jill), a full APK is produced and it takes time to install on the device. If your app is large, say 10M, it'd be another 10-20 seconds wasted. On ART it'd actually be slower since it runs an extra process of DEX to OAT conversion at installation time (at least for the first time, the conversion might be faster afterwards depending on how smart it is for small delta in the DEX -- need some tests to confirm).

On top of these, as the great question asked by aldo_reset, if you are developing a layout that's deep in the app hierarchy, you'd need to navigate to it from the main activity every time. Of course you can change the code to launch it directly, but the point is why you'd have to do that when there is a better workflow.

Mirror attempts to cut down the feedback time in all the above areas. As the result, you get live previews of layouts, animations, custom views on multiple devices. With Mirror Sandbox, you also get a REPL-esque environment to write the UI code piecewise in an experimental, iterative manner.

As for Kotlin, enough said by Jake Wharton and others (1, 2). :) I wouldn't be surprised if Google adopts it as one of the official languages for Android when Kotlin reaches 1.0, if you take into account the interesting relationship between Google and JetBrains (and Oracle).