OberonCore

Плюсы, видимо, такие:
* лёгкая переносимость
* доступ к библиотекам
* компиляторы Си хорошо оптимизированы, поэтому можно ожидать высокого быстродействия

Минусы:

* когда вы пойдёте это сертифицировать, проверке подлежит весь стек, а не только обероновская часть. Значит, безопасность такой системы берётся по слабому звену, т.е. равна безопасности Си
* делать любую реализацию Оберона - это значит _отдавать_ в Оберон и _брать_ из Оберона. Отдаём в Оберон ещё плюс одну реализацию Оберона, а берём из Оберона его популярность (она на самом деле в какой-то степени есть и по сей день). Если Оберон транслируется через Си, значит, в каком-то смысле "Оберонщики не смогли". Не смогли сделать свой (пусть упрощённый) аналог gcc или llvm, покрывающий все платформы. А значит - эрозия изначальной жизненной силы Оберона, который был как раз "системный язык, но не Си, а лучше" и в этом был один из его основных смыслов. Для каждого проекта нужно оценить, что здесь перевешивает.
* Моё убеждение, исходящее из опыта, состоит в том, что двухэтажные конструкции такого рода всегда хуже одноэтажных. Сам по себе процесс двухэтапной компиляции означает, что у вас два лексера, два парсера, два способа сборки, две системы сообщения об ошибках, две системы обработки ошибок, двухэтапное отображение места ошибки в компиляции, два источника ограничений, два источника ошибок в самой реализации и всё это на самом деле надо знать, а разработчику языка поддерживать на плаву. Не получится обойтись знанием одного Оберона. Да, иногда они могут быть почти так же хороши, а иногда даже чуть лучше, но это либо стоит неимоверных усилий, либо обеспечена изоляция слоёв, как например программисту на Javascript можно не знать ассемблера, хотя js иногда транслируется для исполнения в машинный код.
* Сборка мусора. В Си нет способа обойти стек вычислений. Поэтому ометание стека либо не обеспечено (например, при консервативной сборке мусора, я показывал пример падения такой системы), либо делается по-хакерски с соответствующими рисками. Стек обероновских программ ещё можно как-то контролировать. Но такие системы имеют смысл, когда можно вызывать Си из Оберона и иногда даже наоборот. В этом случае стек представляет из себя смесь стеков разного сорта. Монолитные оберон-системы на железе лишены этой проблемы, поскольку там весь стек под контролем разработчика
* Производительность процесса компиляции. Понятно, что двойная компиляция будет кратно медленнее одинарной
* доступ к библиотекам озаначает вызов функций на Си из Оберона и обратно, т.е. вместо защищённых конструкций, таких, как массивы, нужно использовать незащищённые, такие, как указатели. При этом опасность работы с сишным кодом не только растекается по всему приложению, но и существует опасность повреждения обероновской кучи некорректно вызванным или некорректно написанным кодом на Си. Об это довольно легко сломать зубы.

Практика показывает, что, возможно к сожалению, стандартизация распространённых компиляторов Си далека от идеальной. Зачастую даже использование другой версии того же компилятора решает конкретную проблему, но это заставляет задуматься.