A sua intro dá a entender que o javascript poderia substituir Ladder e outras linguagens da IEC61131-3, mas logo em seguida "O Desafio" já apresenta a proposta como uma camada de integração. É preciso ter cuidado aqui, a diferença é significativa!

Quando se trata da parte de monitoramento e supervisão, não vejo problema. Acho sim que a camada frontend da automação (IHM ou Supervisório) pode e deve evoluir.

Mas a parte de comando e controle efetivo tem que ser confiável e robusta. O controle direto do hardware tem que continuar sendo feito por um PLC com lógica determinística. Não é só preferência de arquitetura, é segurança física e norma técnica. Se a gente olhar pra NR-12, por exemplo, o maquinário exige sistemas de falha segura que um runtime JS jamais vai conseguir garantir. Sem falar na própria IEC 62443 (Modelo de Purdue), que exige justamente essa segregação estrita das redes para que a camada de TI não interfira no determinismo do chão de fábrica.

Sobre a stack em si, confesso que não consegui ver muito sentido no Next.js. Que valor real ele agrega aqui? Como estamos falando de um SCADA local, rodando na máquina do cliente numa rede fechada (OT), embarcar todo aquele overhead de SSR e roteamento do Next não me parece a melhor escolha. Um React puro (com Vite, por exemplo) consumindo o backend não faria a mesma coisa de forma bem mais leve?

E considerando que vc envia e recebe dados via Modbus, é claro que essa comunicação não tem como rodar direto do browser ou de um client puro em Electron. O sistema obrigatoriamente depende dessa camada de backend rodando por baixo pra agir como driver. E é justamente aí, no backend em NodeJS lendo Modbus na porta serial, que mora a minha maior preocupação.

Como o Node é single-threaded e o Garbage Collector não é determinístico, se a sua taxa de varredura (polling) precisar ser muito rápida, o Event Loop fatalmente vai engasgar e você vai ter perda de pacote ou jitter na rede. Pra gerenciar esse nível de concorrência e I/O industrial direto, linguagens que lidam melhor com multithreading (como C#, Java, Go ou Rust) costumam dar muito menos dor de cabeça no longo prazo.

E como o contexto exige segurança e robustez lidando com buffers binários e conversão hexadecimal, acredito que vc deveria adotar no mínimo Typescript no lugar de Javascript puro. Fica muito arriscado depender de tipagem dinâmica pra garantir a previsibilidade da estrutura de dados e não quebrar a aplicação no runtime, na frente do cliente.