What does an RTOS actually give you that a super-loop doesn't?

Three core things. First, independent tasks with priorities: each activity is a function with its own stack, and the scheduler runs the highest-priority ready task, preempting lower ones, so a time-critical task isn't stuck behind a slow one in loop order. Second, blocking that yields: when a task waits on a delay, a queue, a semaphore, or I/O, it's moved to a blocked state and the scheduler runs other ready tasks, so waiting doesn't waste CPU or stall the system the way a blocking call in a super-loop does. Third, structured inter-task primitives, queues, semaphores, mutexes, for communicating and synchronizing safely between those concurrent tasks. Together these give you the illusion that each task has its own CPU, with the kernel multiplexing the real core among them by priority and readiness. The super-loop has none of this: it's one flow of control, cooperatively running each step to completion, where blocking stalls everything and priority is whatever order you wrote the calls in.