Bear in mind that this 10mb is not a fixed multiplication factor. Like, doubling you code size doesn't double your binary size with native-image because that base contains a lot of stuff that's generic. Not just GC but stuff like support for timezones.
It also contains a cached heap (in fact most of it is cached heap) which is one reason these binaries start as fast as C programs do. Especially important for Clojure where the runtime and libraries are written in such a way as to do lots of unnecessary work at startup. Native images can cache all that so you get rid of the startup overhead of Clojure itself.
That begs the question: if Clojure is so inefficient, that a program written in it needs 10 MB of some "cached heap" just to start as fast as a C program, and it does a lot of unnecessary work at startup, why use Clojure and this Jank (great name lol) in the first place? We have Rust, after all. I mean, creating an optimizing native compiler for any language is not an easy task, there must be some seriously powerful stuff in Clojure to warrant such an undertaking. Or just madness.
Rust and Clojure address completely different domains of problems.
Rust is competing with C++ for writing low level systems, whereas Clojure is designed for writing business applications.
Low level systems tend to have stable and well understood requirements, whereas the same cannot be said for business applications. Efficiency is not a primary concern of business applications, but flexibility is. The efficiency of Clojure is often "good enough" for business application, and there is no peer in flexibility. This explains the many fintech companies using Clojure, as well as many other B2B companies.
A dynamically typed Lisp has virtually nothing in common with Rust. A cached heap can benefit literally any language which is why it's an optimization found in some programs written in C or C++ as well.
Also, Rust binaries have been of comparable size in the past. Check out this question where someone asks why Hello World is 3mb even in release mode:
This 3mb doesn't have any cached heap, doesn't have any garbage collector, doesn't have support for high quality exceptions and doesn't have much in the way of a cross platform abstraction, whereas the Clojure-as-native binary has all of those and more.
There's a giant pile of things you can do here to try and reduce Rust's binary size:
Rust gets great press and HN is flooded with "let's do it in Rust" type comments. But I think sometimes we need a reality check. Rust is an extremely different language to most others, even C. The combination of the borrow checker+everything async is not obviously better than everything else, not even in the low level domains even though Rust is deservedly picking up loyal users there. The moment you care about development speed i.e. for the sort of apps Clojure was designed for, you're going to be better off with a GC and a strong runtime that abstracts the platform well.
It's like they have not seen how much engineering resources and talent have been put into V8 and JVM GCs, and it's only because of these state of the art GCs (and JITs) that Clojure is bearable and practical for day to day use.
I'm almost sure the author would drop the project as soon as he realizes and lives the frustration of not being able to come anywhere near close to the performance of Clojure in the JVM.
It also contains a cached heap (in fact most of it is cached heap) which is one reason these binaries start as fast as C programs do. Especially important for Clojure where the runtime and libraries are written in such a way as to do lots of unnecessary work at startup. Native images can cache all that so you get rid of the startup overhead of Clojure itself.