What can you do with just a super-loop and interrupts before reaching for an RTOS?

A great deal, and recognizing this avoids unnecessary RTOS complexity. The pattern is: handle time-critical and asynchronous events in interrupt service routines that do minimal work and hand off via shared structures, use ring buffers as the producer/consumer hand-off between ISRs and the main loop (so a fast UART or sensor ISR enqueues and the loop drains at its own pace), and structure the main-loop logic as state machines so each activity advances a little each pass without blocking. You add a periodic timer interrupt as a time base to schedule activities at different rates (a simple cooperative scheduler: "run this every 10 ms, that every 100 ms") and keep every main-loop step non-blocking so nothing starves the others. This cooperative, event-driven, non-blocking super-loop handles multiple activities at different rates with deterministic, easy-to-reason-about timing and no per-task stack overhead or concurrency-bug class. You graduate to an RTOS when you genuinely need preemption (a high-priority task must interrupt a long-running lower-priority computation, not wait for it to yield) or when blocking I/O and many independent flows make the cooperative state-machine bookkeeping unmanageable. So the honest answer is: most of what people reach for an RTOS to do, a disciplined interrupt-plus-state-machine super-loop already does, the RTOS earns its keep specifically when you need preemptive multitasking and blocking semantics.