Ну, поскольку большинство трансляторов Оберона в другие ЯВУ являются открытыми, то всегда есть очень заманчивый путь дорабатывать транслятор по ходу разработки проекта, собираемого этим самым транслятором.

Мне думается, что выбор более "готового" средства разработки "из коробки" (передача контроля над средством разработки полностью в руки "третьей силы") вызван полным нежеланием в процессе работы над проектом отвлекаться на само средство разработки. И пусть даже развитие средства разработки может быть повёрнуто "третьей силой" "не в ту сторону" — это никого не смущает. Так мы получаем проекты, которые можно собрать, к примеру, только определённой версией Borland C++ Builder.

Мне удалось использоватьOfront+на двух последних местах работы, не считая разных хобби-проектов. Правда, его приходится изредка дорабатывать до нужных фич, но это приемлемо для проекта, который ведёт, в основном, один человек (или даже маленькая команда разработчиков). Все аспекты в одиночку не ухватишь.

И, опять же, многие разработчики исходят из того, что "где-то в этом готовом средстве разработки фича X уже сделана, и не надо делать снова". Хотя чем крупнее разрабатываемый проект — тем, как правило, больше смысла делать его на средстве разработки, которое сам полностью контролируешь на всех уровнях. Лично моё мнение. А на практике 99% коллективов всё равно выбирают другие средства, готовые. По разным причинам, даже не всегда связанным с навязыванием их менеджерами, далёкими от программирования. Ещё ведь есть аспект "платформы X и программных средств для её поддержки производителем": например, Android и Android SDK. Ну кто переплюнет Android SDK на Обероне? В лучшем случае, можно к нему пристыковаться, но кривенько, самопально. Вот и получается, что у нас чаще проекты встраиваются в готовую инфраструктуру, поэтому для них разрабатывать на заточенных под эти инфраструктуры средствах — просто тупо проще для программистов и экономически выгоднее для менеджеров. Вот когда каждый второй проект будет мало завязан на интеграции в существующие инфраструктуры — тогда может будет больше смысла проектировать всё с нуля на Обероне. Да и то — делать это именно на Обероне смогут (и захотят) только те программисты, кто понимает достоинства Оберона. Или те, у кого к Оберону (Паскалю) привязки из ВУЗа или школы.

Ещё судя по моему пиарусреды разработки XDevнафоруме ZX-PK.ru, люди попросту не понимают зачем транслировать Оберон в Си, если можно сразу писать на Си. И таких людей не так уж и мало. И объяснить им что-то чрезвычайно сложно. В процессе такого диалога всё обычно скатывается в срачики "Паскаль vs Си", "Страуструп vs Вирт", "реальное программирование в продакшене" vs "академическое теоретизирование" и т.п. В конце концов, это надоедает. Надо с младых ногтей оберонщиков формировать. И тогда пусть мы даже не получим широкое использование самого Оберона, но такие программисты будут всё равно тяготеть к более правильным инструментам разработки, что в целом благоприятно скажется на отрасли.