If you think ART is an AOT system, you might want to refresh your understanding of the system. ART has had a JIT for a long time now. Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash. (And ART already has sub-millisecond GC pause times.) It's good and healthy for a language to have multiple implementations and there's no obligation whatsoever on the part of the Android people to switch to Oracle's JVM.
"But as long as your system isn’t heavily over-provisioned, you can expect to see average GC pause times of around 0.05ms (50µs) and max pause times of around 0.5ms (500µs)."
https://malloc.se/blog/zgc-jdk16
Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash.
The ART features are not exposed to the language design. The JVM features in addition to the order of magnitude performance impact it will have (cf previous comment) needs to be supported in order to maintain interop with future JVM languages versions. (cf previous comment)
It's good and healthy for a language to have multiple implementations no it's much healthier to have one that reap most of the benefits through collaboration. Hence why Android try to merge its patchset in the Linux kernel instead of duplicating it's million commits.
Sure, HotSpot might have some features ART lacks, but ART has features that HotSpot lacks, so it's a wash.
Technical excellence unfortunately isn't an obligation. Or at least until the system becomes unsustainable (Cf interop) but then when it comes it is too late.
