The compiler consumes a JAR-file:
native-image [options] -jar jarfile [imagename] [options]
so it can be possible to scan all classes and resources without reflect.json, resources.json, etc. Why do we need to specify all files getting from the classpath or via Java Reflection? In my opinion, the performance issue is out of scope. Because it will be better to support any library even if it will be slower than could be.
The resulting executables are optimized to run a specific application, not ANY application.
The main limitation is not what's included or not, it's the fact that you cannot load new classes at runtime.
Any library/application that doesn't depend on loading dynamically-generated classes at runtime can be perfectly supported by native-image with proper configuration.
It's indeed possible to include the whole java.base, all your dependencies... the final executable will have more "features" at the expense of (larger) size and compilation time.