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.
Don't blame the JVM for Clojure's quality of implementation.