Mi situación específica, cuando uso un lenguaje de script interpretado en una aplicación principal:
Hay un dispositivo externo que realiza varias funciones. Mediciones, control, lecturas. Es bastante "tonto" en sí mismo y requiere un control preciso, paso a paso, que incluye muchos estados de espera y toma de decisiones ad hoc en el lado del mecanismo de control.
Se requieren varias funcionalidades del dispositivo en varios puntos de la aplicación principal, en diferentes momentos, a menudo bajo demanda. La aplicación principal no permite estados de espera como tales, todo debe hacerse con máquinas de estados finitos.
Ahora, quien haya escrito una máquina de estados finitos sabe que implementar un estado de espera es efectivamente al menos dos, a menudo tres o cuatro estados internos de la máquina. Implementar veinte estados de espera para varias funciones (y esperar sus respuestas y reaccionar en consecuencia) del dispositivo externo sería una experiencia muy, muy frustrante.
Entonces, en cambio, hay estados de "ejecutar una función de no esperar", "ejecutar una función de bloqueo", "ejecutar una función de bifurcación / condicional / salto" en la máquina de estados finitos, quizás seis estados en total. Y hay scripts de control que se programan para su ejecución, que luego son ejecutados por el intérprete que controla el dispositivo externo y sus resultados se colocan donde son necesarios.
En resumen, la aplicación: en un RTOS, el uso de un lenguaje de script interpretado interno puede reducir enormemente la complejidad de realizar tareas abundantes en estados de espera (funciones de bloqueo).