So, we've now got a responsive system that is able to reliably process interrupts. Perhaps we've configured a DMA controller to take care of the heavy lifting for the communication peripherals as well. Why do we even need an RTOS? Well, it is entirely possible you don't! If the system is dealing with a limited number of responsibilities and none of them are especially complicated or time-consuming, then there may be no need for anything more sophisticated than a super loop.
However, if the system is also responsible for generating a User Interface (UI), running complex time-consuming algorithms, or dealing with complex communication stacks, it is very likely that these tasks will take a non-trivial amount of time. If a glitzy eye-catching UI with lots of animation starts to stutter a little bit because the MCU is dealing with collecting data from a critical sensor, that is no big deal. Either the animation can be dialed back or eliminated and the important part of the real-time system is left intact. But what happens if that animation still looks perfectly good, even though there was some missed data from the sensor?
There are all sorts of different ways in which this problem plays out every day in our industry. Sometimes, if the system was designed well enough, the missing data will be detected and flagged (but it can't be recovered: it is gone forever). If the design team is really lucky, it may even have failed in this way during in-house testing. However, in many cases, the missed sensor data will go completely unnoticed until somebody notices one of the readings seems to be a little bit off ... sometimes. If everyone is lucky, the bug report for the sketchy reading might include a hint that it only seems to happen when someone is at the front panel (playing with those fancy animations). This would at least give the poor firmware engineer assigned to debug the issue a hint – but we're often not even that lucky.
These are the types of systems where an RTOS is needed. Guaranteeing that the most time-critical tasks are always running when necessary and scheduling lower priority tasks to run whenever spare time is available is a strong point of preemptive schedulers. In this type of setup, the critical sensor readings could be pushed into their own task and assigned a high priority – effectively interrupting anything else in the system (except ISRs) when it was time to deal with the sensor. That complex communication stack could be assigned a lower priority than the critical sensor. Finally, the glitzy UI with the fancy animations gets the left-over processor cycles. It is free to perform as many sliding alpha-blending animations as it wants, but only when the processor doesn't have anything else better to do.