For what GP mentioned ("systems automation") depending on the JVM (as one would with Clojure) is kind of a non-starter, due to the long startup time. By contrast, Clojurescript (essentially the same language, but compiled to JS instead of JVM bytecode) can run in something like Node.js, where startup times are considerably faster.
Edit: this new development (CLJS compiled with CLJS) is remarkable because previously, compiling CLJS required a running JVM. One could still compile automation scripts and run those, but that wouldn't really be true to the "scripting" style anymore.
You can dynamically compile and run ClojureScript scripts so long as you have properly hooked things up to a JavaScript engine. I've started on an effort that makes this easy OS X, wrapping JavaScriptCore and I could see similar efforts for Node.js. Here's what I've been working on: http://planck.fikesfarm.com It can run scripts you have on disk, etc, and it has basic file I/O capabilities at the moment so you can write simple text processing scripts, for example.
Just for DX / ergonomics, I'd like to mimic more of the file I/O stuff that you have in Clojure, especially the ability to cope with streams. And then perhaps having network I/O would be interesting as well.
Then there is the `clojure.java.shell` namespace that could prove very useful for scripting.
Since none of your other responders said this, I will also point out the most common/obvious reason: you're building a website in Clojure, and want to continue using it for your front-end work, too.
Well, that's 300k of gzipped code, so while the bandwidth isn't huge (300k is barely a large image these days), that's a ton of code to be parsed, and might be too much of a CPU hit for anything mobile.
Oh, my comment wasn't at all clear, but I was talking about inclusion on web pages, where you'd be flicking forward and back between them. In which case even 50ms on top of the rest of a page load would be hurting you.
I'm sure it's fine for a SPA, and for a mobile app it's a total non issue. Actually I'm planning to use it for one with React Native myself.
Luckily, people will probably not be including the full compiler lightly; I just wanted to point out that it's not as cheap as a jpg of the same size would be, an impression I thought the parent comment was giving.
You'd probably not want to use this on websites, unless you want to be able to compile code directly in the browser, such as when you're making an interactive tutorial or similar. Otherwise, you're better off with stripping out all of those parts.
There are a lot of commonly used mobile libraries that are larger than this. Some of them (e.g., JQuery Mobile, which weighs in at several megs) make this look tiny by comparison.