With the caveat that it's not a one-way trade-off of "better" vs. "good enough for the expectations". If your customer calls you and says "My industrial CNC controller crashed and ruined a $20k prototype, is this my fault or yours? Here are the logs." and your answer is "the browser was running bad javascript that locked up too many threads for too long so it stopped counting the encoder for 20 ms", they're going to tell you that a servo amplifier has no business doing any of that stuff.
Some devices do need to be on the Internet and should therefore be running general-purpose operating systems. They may need to interact with other devices that run real-time operating systems (or bare metal, like the Teensy). Some IoT devices try to bridge the gap. Knowing and deciding which side you're on is critical.
And I think the best answer to pennypinching on the BOM is to separate your concerns into separate devices/apps. Make the CNC HMI handle the Internet connectivity. Give it one NIC that hooks up to the Wifi, let it run whatever Javascript you want. On a separate NIC, talk whatever flavor of industrial protocol you prefer on the machine. Do not bridge the two. In the servo amp, use a bare-metal/RTOS microcontroller. That device doesn't need to be burdened with Linux, and in fact is made worse by it: Let it be what it is and no more. In 20 years, it should still run reliably, regardless of whatever newfangled holographic VR HMI is loading in motion profiles.
