Наличие этой опции помогает в ряде игр и мобильных приложений.В работе с MDM-приложениями с паттернами MVC или MVVM, которые берут из баз данных большие grid-ы, обрабатывают и потом удаляют их из памяти наличие JIT-компилятора и GC и упрощают жизнь, и предоставляют в большинстве случаев высокопроизводительное решение из коробки.
В случае с С++ массовое удаление большого количество экземпляров многократно унаследованных объектов с динамической памятью приведет к потере производительности, если сделать вызов delete. Для решения этой проблемы пишется логика фонового удаления в отдельном потоке. При наличии большого количества мусора возникающего в разное время приходится писать логику подбора времени когда производить те или иные фоновые операции очистки. В конечном итоге это приводит к собственной реализации GC в крупном приложении. Самый едкий вопрос в том, что будет быстрее, имеющийся GC в C#/Java или то что разработчики напишут сами. Ответ на этот вопрос не очевиден от слова "совсем".
В некоторых случаях, наоборот, требуется отсутствие GC и JIT, потому что всё что происходит в приложении по вопросам производительности значительно меньше, чем эти подсистемы в стандартной библиотеке и их хотелось бы убрать.
JIT компиляция и наличие GC в платформе иногда приводит к замедлению, а иногда наоборот ускоряет и упрощает жизнь разработчику одновременно.
Например, в Unity сценарии, которые отрабатывают на события в pipeline неизменны по своей структуре и манипулируют стандартными классами. Для ускорения их отработки Unity транслирует C# в IL и затем в C/C++, чтобы получить нативный код. Этот исторический костыль жив до сих пор, потому что, справедливости ради, Unity до сих пор тянет за собой собственный форк всего .NET, развитый в свое время из Mono и только сейчас села переписываться на актуальную версию. Native AOT - одна из фич которая была им сильно нужна. То же самое касается маленьких мобильных приложений, в которых потенциальный выигрыш в производительности не имеет значение, но вот выигрыш в энергопотреблении важнее (GC и JIT тут опять мешают).
Когда у разработчика есть выбор какие части проекта он пускает в обычном виде, а какие собирает нативно - это не возврат к тому, что было 40 лет назад, а удовлетворение потребностей разработчиков здесь и сейчас. При этом эти коммерческие разработчики никогда и ни при каких условиях не пересядут писать свои проекты на С/С++ ввиду того, что скорость разработки и цена этой разработки не подходят под их проекты.
