Yes (on the J2Cl side; not GWT 3 yet, it's actually yet to be defined what exactly will be GWT 3: encapsulate J2Cl and Closure Compiler into a "monolithic" tool? or mostly just libraries to be used with J2Cl and Closure Compiler, probably along with Maven/Gradle/etc. plugins tying things together)
No yet, but if you want an idea of compilation performance, find a JS project with an equivalent number of files and classes (actually, J2Cl produces at least two JS files per Java file, but one ES6 class per Java class) and run the Closure Compiler on it.
One thing we don't know yet how it'd work is "permutations": hopefully there shouldn't be "permutations" per browser anymore, but how about i18n? and then how to select the appropriate "permutation" at runtime?
Also, for development, there should hopefully be an equivalent to "draft mode" / "super dev mode" where generated sources are simply concatenated, without further processing (except maybe some basic minification). AFAIK, this is something they have in Closure Compiler that should be open sourced soonish.
That said, J2Cl / GWT 3 might require some specific project layout (it might become impossible to mix client and server code in the same Maven module; hopefully a split layout like in
https://github.com/tbroyer/gwt-maven-archetypes will continue to work with minimal changes to the POMs) so the first thing in any case is to "clean up" existing codebases; and this hopefully could make your build more incremental, so you wouldn't need to recompile your GWT client code when you only changed server-side code.
For now, make sure you take full advantage of GWT incremental compilation and your build tool's incremental build support (Maven is "broken by design" on that front, but should work quite well nonetheless with recent plugin versions; but what I mean primarily is "don't 'clean'")