Remember that the JVM was originally developed by a company that sold big-iron server hardware; the software on it would typically run for weeks at a time. If you have to make a trade-off during development that sacrifices startup time for overall performance, take a guess as to which one is going to win.
Android does not have a JVM and Android's Dalvik/ART is not optimized for dynamic languages like the official JVM is. And you won't see this difference when comparing Scala against Scala.js on Android.
At this point you're comparing design choices in Javascript vs Java. Except that I don't buy that the JVM's bytecode is less efficient to interpret than Javascript is. The official JVM actually has a very similar execution model to modern Javascript VMs, with code being first executed in interpreted after which it starts optimizing and compiling the hotspots, with Java's bytecode being optimized to be interpreted first. Android's ART does it differently though, compiling the bytecode ahead of time to native, which is cool for the purposes of Android but misses runtime optimization opportunities for dynamic languages like Clojure.
So no, what actually happens is that normal Clojure insists on loading all namespaces that are used in the program, setting its symbols, vars and functions in the process. Clojure is also a dynamic language and this involves call sites that are not very inline-able and that Android cannot optimize as well as Oracle's JVM can. These problems don't exist with ClojureScript, which in the end is just plain Javascript that also happens to be tree-shaken by the Google Closure compiler.
Didn't realize clojure was dynamic typed when I made my previous comment in the discussion. That explains a lot about performance, ART and java 6 though.
