En mi experiencia, he visto microcontroladores y PLC utilizados en entornos industriales.
El factor determinante es "¿Quién va a apoyar / mantener / modificar el equipo después de su puesta en servicio?"
En entornos industriales, se dedica más tiempo a leer (vea la búsqueda de fallas) que a lo que se dedica a escribirlo. Esto no significa que esté tratando de encontrar problemas en el código, sino que lo esté utilizando para ayudar a diagnosticar problemas en el campo. A menudo, las personas que deben realizar tales averiguaciones son electricistas, que se sienten más cómodos leyendo esquemas eléctricos que códigos en un formato de texto (de ahí la popularidad de los "lenguajes de programación" de tipo gráfico, como la lógica de escalera). En sitios más grandes, con ingenieros de automatización dedicados, esto se vuelve menos importante.
Estrechamente relacionado con lo anterior están los problemas de inercia histórica para una solución particular. Los antecedentes técnicos del personal y la experiencia previa con hardware / proveedores conducen a requisitos previos para proyectos que generalmente se organizan en torno a líneas como ("ya usamos el proveedor X y tenemos repuestos a mano; cualquier cosa implementada en el futuro debe usar X-YZ ").
También relacionado, y cada vez más problemático en los últimos años, está "Cómo se va a comunicar este equipo con el resto de mi equipo / fábrica / sitio / empresa". Esto generalmente se resuelve previamente para los PLC y es un problema mayor para las soluciones de microcontroladores de bajo volumen.
He visto microcontroladores implementados donde se justificaba una solución muy personalizada (pero luego, por lo general, solo se implementa como un proyecto de proveedor y es compatible con el proveedor). Las razones normalmente están relacionadas con la velocidad de ejecución o la necesidad de tener el hardware y el código muy cerca (sin posibilidad de demoras en la comunicación y el requisito de separar el proceso crítico de otro código no relacionado)