There would still be JVM startup time even if some parts of the process delegate to native code. Though the OP acknowledges this and still thinks this is the best approach (and plans on mitigating the issue as much as possible). I'm of a similar mind: desktop apps tend to be long-lived and a few tens or even hundreds of milliseconds at startup shouldn't really matter.
JVM startup time is not great but it's not horrible either. Especially in the context of desktop apps that are often started once and kept running for a long time. With some care it is definitely possible to spin up a JVM and display an initialized window within 1 or 2 seconds. Which is roughly the same time as Gimp or Krita or Thunderbird take to startup on my machines.
I even have a few git-style CLI tools that bootstrap a JVM on each invocation without using optimized graalvm/native images.
JWM (a window library that I plan to use) shows a fully initialized window in 600-700 ms on M1 mac for me. That’s without Clojure, but with JVM overhead
Just to add some reference to why it can take a long time to start a REPL (for example):
> As it turns out, Clojure start time is a complicated and multi-dimensional topic. Clojure projects are slow to start not only because of JVM — JVM itself starts in ~50 ms — but because of JVM specifics the classes are loaded slowly. Clojure projects are slow to start not only because of Clojure — Clojure itself starts in ~1 second — but because of Clojure specifics, the namespaces, especially not AOT-compiled one, are loaded slowly. And so on.
