The PLC developer experience makes it possible for average technicians to do some things (like, things people typically use PLCs for) in days that would take average embedded C programmers weeks. It's worth taking a look at.
But in many cases you have large-ish systems that have various lookup tables in PLC memory, do non-cyclical communication (ie. communicate with something external over some “normal” protocol, not over fieldbus) or even just contain many instances of the same logic (there are PLC families that cannot do indirect accesses to the process image memory, so if you want the PLC to do 12 instances of the same trivial logic, there is no way to do that in a loop and you have to copy-paste that 12 times…). In my opinion for many of these situations just programming the thing in “real” programming language (even while preserving the cyclic process image model) would be very beneficial.
There is a certain amount of pain and inconvenience incurred for a highly deterministic outcome that is otherwise unachievable without very significant expertise.
can you give examples where that is the case? It's hard for me to believe this. The embedded C ecosystem has all the best practices available (software and hardware abstractions, libraries and frameworks, unlimited open source availability, transparent tool chains, testing, build automation, continuous deployment, huge developer pool with shared)
Does PLC match ALL this and even go beyond?
Plus PLC hardware has a level of inbuilt hardware diagnostics that would take months to code and prove from scratch.
PLCs also replaced a hell of a lot of very unreliable wiring and electromechanical hardware.