I do find it somewhat amusing that Android went from Dalvik precompiled to Dalvik JIT, to ART precompiled, to ART JIT.

It's actually a rather logical set of steps, it follows the same pattern as elsewhere probably for the same underlying reasons.

Compiled once is easier to develop, prove correct and validate functionality. Just in time offers convenience in deferring compilation, but increases storage requirements and can decrease the initial runtime performance due to compiling the code. If you have spare cores this starts to make more sense. If you have a mechanism of profiling and automatically tuning the optimization of frequently used codepaths / infrequently used ones then JIT also starts to have payoffs (this is where human hours making a smarter compiler pay off across many applications that don't warrant the human hours optimizing directly).

Another interesting aspect of the evolution of the Dalvik and ART runtimes is that they are runtimes for (mostly) battery-powered devices. A JIT compiler was an obvious next step but less obvious is that it had to be battery conscious. It was designed to JIT as little code as possible to attain the greatest gain in performance as possible. That's not how you would design a JIT compiler for server Java!

Dalvik interpreted was the first step. You could sort of call it "precompiled" if you call dex a precompiler.

Also, the system update install process will happen while the phone is in use, and only require a reboot after installation is finished. The whole process will be much faster.

Not only that, but Android N will be able to boot all the way to the lock screen before asking for the password, and even support functionality like phone calls, limited notifications, or alarms (so if your phone reboots in the night you'll still get woken up in the morning).

Only for new devices that support it