For a device that reads a few sensors, runs a control loop and talks to one interface, an embedded Linux system is usually the wrong answer. Not because Linux is bad, but because it solves problems that device does not have while introducing several it cannot afford.
Start with determinism. A bare-metal or RTOS design can guarantee that an interrupt is serviced within a known number of microseconds. A general-purpose kernel with virtual memory, demand paging and a scheduler serving multiple processes gives you an average, and averages are not what a motor controller needs.
Then boot time. A microcontroller runs application code milliseconds after reset; a Linux system takes seconds. For anything a person switches on and expects to work — an instrument, a tool, an appliance — that difference is the whole user experience.
Then cost, power and maintenance. Linux needs external RAM and non-volatile storage, a more capable processor and usually a power management IC. It also brings a lifetime obligation: a networked Linux device carries a userspace with CVEs that arrive on someone else’s schedule, for as long as the product is in the field. A bare-metal device with a small, audited stack has a far smaller attack surface and no upstream to track.
Linux earns its place when you need a filesystem, a full network stack, a display framework, or the ability to run software you did not write. Below that threshold, an RTOS on a modern 32-bit microcontroller does the job with less hardware, faster start-up, predictable timing and a maintenance burden the manufacturer actually controls.