This is exactly what I'm out after. In practice, slow startup doesn't hurt you, unless you use Clojure like you would use NodeJS or any other interpreted language, but that's not how the Clojure community uses Clojure, because it wasn't meant for that.
Knowing how to use a tool for the job it was designed is not a "workaround", it's part of the documentation or knowing how to actually use it.
If you don't want to adapt to your tooling then yeah, don't give that tool any of your time, because you'll just fight it. Trying to use something but not following what it recommends, is just a waste of everyone's time.
Just like I wouldn't spend time trying to use Docker containers as VMs, you should not use Clojure if you constantly want to restart the process. Or sending high-quality videos via email. Or using VGA cables to send TCP packets. Or trying to use Rust to do meta/dynamic-programming. It wasn't made for that workflow, so why would you try to use it that way?
I don't really care about what you or others adopt, the benefits of Clojure is not that everyone/a lot of people use it, but the benefits you get from adopting to the tooling it provides. So if people are not ready to give that a try, good riddance, I won't lose anything because of it.
I don't think you need to explain that, it's a conservative ecosystem for experienced devs, that was the target niche it was always aiming for. It's intentionally built to not reach that level of "mass adoption", mass-adopted, market dominating tools are one small subset of the set of useful software tools.