Na minha experiência, vi microcontroladores e CLPs usados em ambientes industriais.
O fator determinante é "Quem vai apoiar / manter / modificar o equipamento depois que ele é comissionado?"
Em ambientes industriais, gasta-se mais tempo lendo o código (veja a localização de falhas) do que o que é gasto escrevendo-o. Isso não significa que você está tentando encontrar problemas no código, mas está usando o código para ajudar a diagnosticar problemas no campo. Freqüentemente, as pessoas necessárias para encontrar essas falhas são eletricistas, que se sentem mais à vontade lendo esquemas elétricos do que códigos em formato de texto (portanto, a popularidade do tipo gráfico "linguagens de programação", como lógica ladder). Em sites maiores, com engenheiros de automação dedicados, isso se torna menos importante.
Intimamente relacionados ao exposto, há questões de inércia histórica para uma solução específica. Os antecedentes técnicos da equipe e a experiência anterior com hardware / fornecedores levam a requisitos de pré-requisito para projetos geralmente organizados em torno de linhas como ("nós já usamos o fornecedor X e temos peças de reposição à mão - qualquer coisa implementada no futuro precisa usar o X-YZ ").
Também relacionado, e cada vez mais problemático nos últimos anos, está "Como esse equipamento se comunicará com o restante do meu equipamento / fábrica / local / empresa". Isso geralmente é pré-resolvido para PLCs e mais um problema para soluções de microcontroladores de baixo volume.
Vi microcontroladores implementados onde uma solução muito personalizada era necessária (mas, geralmente, implementada apenas como projeto de fornecedor e com suporte do fornecedor). Normalmente, os motivos estão relacionados à velocidade de execução ou à necessidade de ter o hardware e o código muito próximos (sem possibilidade de atrasos na comunicação e a necessidade de separar o processo crítico de outro código não relacionado)