Big apps where startup time matters are desktop/mobile GUI apps. These aren't heavily emphasized in the Clojure community (excluding ClojureScript), but they are feasible to build - and I do build some of them. If startup time is reduced by 40%, the end user will definitely notice it.

IMHO, while optimizations in the JVM are always welcome, they primarily address surface-level issues and don't tackle Clojure's core limitation: the lack of a proper tree shaker that understands Clojure semantics. Graalvm offers help here by doing whole-program optimization at the bytecode level, but a Clojure-specific tree shaker could take things further: it could eliminate unused vars before/during Clojure AOT, thereby reducing both program size and startup time. These improvements would happen before the JVM optimizations kick in, making everything that follows a nice extra bonus.