Со "скриптами внутри" его (сборщика мусора) тоже не появится. Он же будет только внутри виртуальной машины, а весь окружающий нативный код как был статическим, так и останется (а именно он в нормальных системах делает всё критичное). Более того, ресурсы для виртуальной машины тоже делают статическими (с точки зрения вызывающего нативного кода). И если есть часть ресурсов под виртуалку заведомо read-only, то это ещё и ресурсов для нативного кода сэкономит (и уж точно это будет чистая статика).

В общем, если знать меру и внимательно "следить за руками" (а во встраиваемых системах без этого никак невозможно), то вполне себе применяют и в серьёзных и условно*** критичных системах.

*** Там больше сложности не в применении скриптования как такового, и тем более не в сборщике мусора внутри виртуалки (при правильной архитектуре вообще довольно пофиг что там внутри) и т. п. Там больше в доказательстве отсутствия влияния всего что связано со скриптами (в основном с самой реализацией и работой виртуальной машины) на тот нативный код, который делает "всю важную работу". Это непросто, поэтому для сильно-сильно критичных штук реально дешевле не использовать совсем. Дешевле в плане всяких сертификаций - не использовать скрипты, дешевле (в некоторых случаях) в плане разработки и всего остального жизненного цикла - использовать скрипты. На сильно критичных штуках удорожание сертификационных моментов запросто может сильно перевесить все "плюшки" от скриптов, поэтому идею скриптования хоронят часто сразу, прямо на уровне идеи.

В общем и целом (в среднем по больнице) вы правы, но дело не в сборке мусора внутри виртуалки...