> А чем это назвать?

Ограничением архитектуры, но уж никак не языка.
Ведь в том же AVR32 вполне возможно запускать код из RAM, несмотря на его Гарвардскую архитектуру. https://ww1.microchip.com/downloads/en/Appnotes/doc32160.pdf

> Где у 32L1 кеш то?

В 32L5 его добавили для решения этой проблемы.

> И что мне это дает в общем случае? Я ж не собираюсь с IR что-то делать.

А почему нет? Я же делаю. Само собой, на основе ранее скомпиленного из языка высокого уровня шаблона.

> Мне JIT вообще не в кассу. Особенно в контейнерах. И хруст кроме всего прочего - нормальный компиляемый ЯП так то. Это его достоинство, имхо: не будет жрать ресурсы в проде на AOT/JIT.

А как тогда делать рефлексию, динамически формируя оптимальный код для изменившихся метаданных? Когда таких данных сотни миллионов сообщений в сутки, рефлексия дает очень заметный выигрыш.
Компиляция в Rust весьма тяжелая. А вызов динамически скомпилированного кода - вообще целое приключение в unsafe.

> А зачем мне что-то компилить в именно контейнерах?

Чтобы не останавливать продуктивную систему для того, чтобы пересобирать и деплоить сотню сервисов из-за изменившихся метаданных. Например, protobuf в Kafka или gRPC можно парсить динамически, но это очень медленно. А можно скомпилировать обработчики для схем, что ускорит обработку почти на порядок. И тут выбор. Или компилировать в CI/CD, что заметно снижает доступность системы, или компилировать на лету, как только сервис обнаруживает сообщение с новой схемой или новой версией схемы.

> Однако универсальность тула - это его очень крутое достоинство.

Ассемблер еще более универсальней. По моему опыту, универсальным швейцарским ножом пользуешься намного реже, чем ответркой, строительным ножом, консервным ножом, ножницами и т.п. Потому что специализированный инструмент удобней и работать им продуктивней.

А на данный момент, имеем грандиозную иерархию классов в .Net.Core, на которой базируется Office 365 и не имеем возможности ее просто конвертировать в Rust, так как её идеология наследования в Rust не поддерживается. Необходимо разрабатывать свою систему структур, типажей и макросов для создания чего-то подобного.

> Потому что дотнет VS прод это не сказать что беспроблемная штука. Особенно в нагруженной среде.

Там проблемы те же самые, что и в любом языке с GC и проистекают они именно из GC. Если включать мозги и максимально использовать стек, то проблемы решаемы.
Ну и следует понимать, когда лучше использовать среду с JIT (CLR, JVM, V8), а когда лучше компиляцию в машинный код.
Лично я против Rust ничего не имею. Сам использую plrust на PostgreSQL. Но он там совершенно не заменяет plpgsql, а лишь дополняет его. Но при этом высоконагруженные функции все равно пишу на C. Потому что на C можно напрямую работать со страницами PostgreSQL, что на Rust слишком сложно и все равно unsafe. А gRPC сервис, продьюсер или консьюмер к Kafka и т.п. - как раз задача для C#.

> Ну вот не дружит GC с хайлоадом в общем случае.

Надо уметь его готовить. Естественно, если нахреначить в каждом методе сотню переменных не в стеке - GC под нагрузкой не будет успевать их собирать. Как я писал выше, нужно понимать, где выиграешь больше: за счет динамической компиляции или за счет издержек GC. Иногда перевешивет одно, иногда другое. Что лишь подтверждает то, что "золотого молотка" не бывает и для каждой задачи следует подбирать свой инструмент.