Форт, Lua и Tcl в каком-то смысле одинаковы. Их можно добавить в крупный проект для описания сценариев. Tcl сейчас очень популярен в электронных САПР, просто для того, чтобы не заниматься настройкой параметров с помощью мыши. Для крупных проектов это может превратиться в кошмар, а скрипт на Tcl очень даже решает задачу. Смысл тут не в том, что он какой-то быстрый, удобный или выразительный, а просто в том, что он позволяет автоматизировать длительные процессы без необходимости пересборки всего проекта.

Отсюда рабочий сценарий. Смотрим на полезные инструменты, не столько языки, сколько фреймворки и библиотеки. Чтобы не заниматься проектированием сложных интерфейсов на все случаи, можно взять набор полезных функций и "обернуть" их в слова форт-машины. Получится приложение на <language + libraries>, у которого будет консоль и возможность выполнения скриптов по запросу.

Я счас иногда работаю с медиавики, где установлен интерпретатор lua и у меня были мыслишики написать на lua интерпретатор форта.
Остановился на том, что это не имеет смысла, потому что неясно какая у форта в данном случае будет практическая применимость

Вот такой вопрос для поисков и размышлений. Вместо того, чтобы писать форт-машину "внизу" и с ее помощью реализовывать все остальное, можно сначала запустить основные компоненты программы на подходящем языке, а потом добавить туда форт-машину для управления ими. Например, Irbis Форт построен вокруг заранее инициализированных виджетов в Lazarus IDE (их там очень много, просто они все скрыты). Идея в том, чтобы можно было на Форте быстро показать нужный набор виджетов и привязать к ним скрипты. И надо сказать, прекрасно заменяет более тяжелые Matlab или Python в простых программах, когда нужно просто срочно что-то посчитать.

Соответственно, это становится не просто "странным языком", а "архитектурным шаблоном Интерпретатор", что существенно более практично и понятно в использовании. Вряд ли кто-то будет активно протестовать против самой идеи встроенного в "тяжелую" систему интерпретатора, тем более что они очень разные. Таким образом, можно подумать на тему связки инструментов, которая сама по себе открывала бы достаточно интересные возможности по быстрому созданию полезных приложений, и при этом управлялась интерпретатором. Понятно, что интерпретатор любой... но в данном случае "любой" - это понятно что :)

Отдельный вопрос - тип ШК. Машинный код, видимо, можно пока отложить подальше, потому что динамическое создание кода и переход на него негативно воспринимается современными антивирусами, да и переносимости нет. Наконец, не в ускорении интерпретатора кроется решение проблемы производительности.