1. Большая переносимость: поставляемый (байт-код) остается переносимым
2. . В то же время, больше зависит от платформы: поскольку JIT-компиляция выполняется в той же системе, что и код , он может быть очень и очень точно настроен для этой конкретной системы. Если вы делаете компиляцию вперёд (и все еще хотите отправить один и тот же пакет всем), вы должны пойти на компромисс.
3. Усовершенствования в технологии компилятора могут повлиять на существующие программы. Лучший компилятор C не поможет вам вообще с уже развернутыми программами. Лучший JIT-компилятор улучшит производительность существующих программ. Код Java, который вы написали десять лет назад, будет работать быстрее сегодня.
4. Адаптация к меткам времени выполнения. JIT-компилятор может не только смотреть на код и целевую систему, но также и на то, как используется код. Он может управлять запущенным кодом и принимать решения о том, как оптимизировать, например, какие значения имеют параметры метода.

Вы правы, что JIT добавляет к началу, и поэтому для него существует ограничение по времени, тогда как компиляция в режиме «впереди» может занять все время, что она хочет. Это делает его более подходящим для серверных приложений, где время запуска не так важно и «фаза разминки» до того, как код становится очень быстрым.

Я полагаю, это было бы возможно для хранения результата компиляции JIT где-то, чтобы его можно было повторно использовать в следующий раз. Это даст вам «опережающую» компиляцию для второго запуска программы. Может быть, умные люди в Sun и Microsoft считают, что свежий JIT уже достаточно хорош, а лишняя сложность не стоит того.