Wouldn't an optimising compiler run contrary to go's goal of fast compilation?

They could use the same front end and enable optimisation passes in the backend with compile flags / heuristics. GHC for example uses for certain flow optimisations "fuel" once it runs out it stops doing further optimisations. For long running applications, ideally the runtime would profile the application during its execution and JIT / optimise based on the live state of the application. The JVM demonstrates that this can have major benefits over AOT compilation.

No, going fast is about not doing work twice. It is about the dependency graph. Go was developed to make dependency analysis very simple, so you recompile a tiny number of files even on massive, complex apps... and don't spend massive amounts of time deciding what to compile, or building stuff up just to tear it down (include all the things, use macros to exclude, etc).

Unless they had a flag... I would think so.