You do have valid points with the "better to avoid mixed criticality when possible" and "isolate the most latency sensitive compontents on dedicated hardware".
I work in embedded software and I have some insight on why the reality often looks very different from this:
Software "cost" works differently. In a startup environment, you can spread the fixed costs for software development on thousands of installs (or even more). Automation software is very different, and solutions are often bespoke; even if you're building and selling machines, the numbers will be much lower than for consumer stuff.
This means that fixed costs for software development matter much more, and that hard developer productivity (as in: how many factories can your PLC programmers automate per year) is much more important. Vendoring dependencies is much more costly, splitting your codebase over multiple subsystems is less desirable (=> overhead for general development, update, configuration management, redundant subcomponents, slower iteration), heterogenous systems are very undesirable (because specialized employees are more expensive to manage and less flexible).
This is why much of the industry is so willing to shell out for "overpriced" PLC controllers (when freely programmable MCUs can be had for cents), proprietary frameworks and what you might perceive as obsolete garbage tooling for HMI/cloud integration: All those things help to build solutions that are "good enough" with less programmers, less training, less specialization and thus, crucially, less software-fixed-costs (that you wouldn't be able to recoup).
One other thing: software being formally correct vs. reliable/robust is much more orthogonal in practice than you might assume, and industry typically cares more about the latter. My perspective is that formalizing/certifying software is (overly) concerned with eliminating lower risk holdouts (think: proving latency bounds on memory allocation or somesuch), while "robustifying" software looks at "actual highest risk" parts first (sanity checking requirements/specifications, avoiding pitfalls for users when configuring/operating your system, fixing false positives).