This is certainly true, but I think that some of it is a question of industrial designs lagging behind the state of the art in computery stuff.

The CPU clock cycle time of any random Cortex-M0+ is on the order of 30 nanoseconds, a much higher clock speed than the microsecond range you're taking about. The microcontroller also has much better response-time predictability than you can get on a basically-desktop CPU, with its TLBs, three layers of cache, DRAM CAS latency, variable latency to open DRAM pages, SMM, Intel ME, high-priority DMA delaying the CPU's RAM access, etc.

ERICI's plan to run Linux under a real-time hypervisor is definitely a thing that can be done, and a thing that is regularly done on cellphones and industrial-control systems, and has been since the 01990s, among other things, with RTLinux and Linux-CNC. But, although I need to say that I lack any experience in the area, I'm skeptical that it is a sensible tradeoff in 02026, where by rearchitecting the entire system to run under a hypervisor you can maybe avoid spending 9.97¢ on a 48MHz Cortex-M0+ https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU... or 17¢ on a 48MHz RV32E CH32V003 https://www.lcsc.com/product-detail/Microcontrollers-MCU-MPU.... I think it made more sense in the 01990s where EMC/LinuxCNC was running on an 80486 that was half as fast as the Cortex-M0+ but cost US$2500. I think it might be a better tradeoff to avoid having any CPUs that have to run "mixed-criticality" workloads, as seL4 calls them — where the same CPU is timeshared between a best-effort Linux workload and hard real-time code. The problem with hard real-time code in industrial automation is that, if it misses a deadline, it can crash your lathe and cost you US$159,532.53. You're depending on your real-time hypervisor to make sure that nothing Linux can do can make that happen.

It seems like it would probably be better engineering now to run the hard real-time control loops on a tiny dedicated computer that costs 37¢, and communicate with the Linux box over I²C or USB or a UART or PCIe or something. To get the response times lower than microcontrollers can guarantee, people seem to be moving to FPGAs. You can get a small FPGA for US$2 now, and the latency from inputs to outputs is typically on the order of 10 nanoseconds, much quicker than a microcontroller can respond from an ISR.

Avoiding one crashed lathe can pay for a lot of microcontrollers.

European RISC-V Industrial Computing Initiative