I've tried it and it does improve start-up noticeably. However, the ergonomics for use are not favorable given how Clojure is typically consumed and used. AppCDS requires pre-creating a list of classes to archive and ensuring that the classpath used to generate the archive is a prefix of the classpath used at runtime.
In most ways people currently use Clojure, particularly at development time when this matters most, there is no support for either selectively determining the correct shared archive to use (which is Clojure version dependent), or ensuring that it is a prefix of the classpath.
Also, in most Clojure apps that are slow to start, they are slow because they either need to read and compile a large number of clj files (AppCDS doesn't apply) or they need to load AOT'ed classes (AppCDS would apply, but you can only use one archive, so using a pre-built Clojure archive prevents this from working). Note that using it with AOT'ed code is usually at odds with what you're doing in development (often not AOT compiling or dynamically reloading).
If you do want to use it in your own app, you could AOT compile an uberjar, then use that to generate an AppCDS archive and use it. I suspect you'd see a big improvement in startup time. However, as mentioned above, this is unlikely to be a good match for development (which, again, is where people most care about it).
BUT, there is ongoing JEP work that may make AppCDS more flexible like https://openjdk.java.net/jeps/350. So the applicability may change eventually!
