When would you choose an RTOS over a bare-metal super-loop?

When the system has multiple independent activities with different timing requirements and priorities that a single loop can't cleanly juggle. Concretely: you need a high-priority event (a control loop, a safety check, a fast sensor) to preempt slower background work (logging, display) rather than wait its turn; you have blocking I/O (waiting on a UART, a network socket, an ADC conversion) that would freeze a super-loop but in an RTOS just yields the CPU to other tasks; or the hand-rolled timing of your super-loop, the proliferating timers, flags, and counters used to fake concurrency, has become unmaintainable. The RTOS gives you tasks with priorities, preemption, and blocking-that-yields, which directly express that structure. You'd stay bare-metal when the job is simple enough for a clean super-loop, when you're so RAM-constrained that per-task stacks plus the kernel don't fit, or when you want the simplest possible timing story for certification. The decision is about whether the concurrency genuinely warrants the RTOS's costs (RAM, complexity, concurrency bugs), not a reflex, plenty of shipping products never need one.