They can only partially. You quoted the answer to this. AOT compiled classes can only load other AOT compiled classes. If one transitive dependency is missing those it’ll fail. A non-AOT library can load both, but once AOT always AOT.
The compiler and runtime are built arround the REPL. Meaning at any point you are free to re-define almost everything at runtime. Loading a file is exactly identical to eval’ing every single clojure form in the REPL manually. Producing the exact same thing byte for byte just hasn’t been a priority, as far as I can tell. Achievable sure, just not with the current compiler.
Let me ask you back: What value do you see in “repackaging” library packages from one package manager to another? And how would anyone even use it?
Let’s assume the user downloads your linked clj-tools package, which then uses deps.edn to resolve further dependencies. It’ll always get them via maven repositories, not yours. Same for all the other “tools” that know how to build a classpath (e.g. shadow-cljs, lein). So, why even go through the ordeal of packaging them in the first place?
Tools are fine, that is useful and can be AOT compiled. Intermediate libraries not so much, unless of course you also offer a way to build a classpath out of those and run a JVM with that? Effectively replacing clj-tools? If you want to build a “custom” guix ecosystem you are free to do so of course, but why?