Well, for a very first point JVM startup time STILL sucks, even with an SSD.
http://blog.ndk.io/jvm-slow-startup.html
http://martinsprogrammingblog.blogspot.de/2012/02/why-is-clo...
If you program directly in Java it can be as fast as Nim or Go.
Granted, if you want AOT to native code, your only option is a commercial JVM.
Especially when Java 1.8 will hit these languages. It reduces build times and startup times since these lanaguages could share their bytecode when it comes to lambda's and such things. With -Xexperimental on Scala 2.11 and changing some things to lambda it will reduce the code size by 10-15% which is a lot in such a big codebase. And I think closure will have such stuff, too. This also means faster startup times. Also Java 9 and Java 10 will also help these languages to improve.
For a long time I played with the idea of using it as common code between Android and Windows Phone, but the performance on Android and outdated CLR support demotivated me to pursue it, so it was back to C++11 (now C++14) for common code.
Currently this will bring a big one: https://github.com/clojure/clojure/blob/master/changes.md#11...
Also Clojure isn't tied to Java 8, it's compatible back to Java 5, so this brings a lot of overhead.
We written a small ERP project and looking forward to have a calculation layer in clojure.
If it's still a concern, you can do what I did a while back and just write the app on top of Node.js. Then the startup time is more or less gone altogether.