Embedded systems tend to be doing things that look more like real-time control applications. Let's say the processor is running a radio. It is important that certain requests form the radio hardware are processed quickly enough otherwise the data isn't ready to transmit in the time slot that it is meant to be in, and you don't meet the standard for that protocol.

In practice though, what people are actually wanting is an abstraction around the concepts of scheduling, and facilities like multi-tasking (with pre-emption), and facilities to communicate between tasks in a thread safe way. Mostly they don't need the 'hard' RTOS aspects (and so this is often referred to as 'soft RTOS').

To explain this a little - your traditional simplistic embedded app while look like 'while(1) {}' at the bottom of main. It will sit in a loop servicing the things that need to be serviced - pulling characters off a UART, waggling the line for the LED to make it flash on the right interval etc.. This is fine for a small app on an 8 bit processor but as embedded applications grow, you have a lot of functionality that is all tied up with each other. What an embedded scheduler does is put the main loop at the bottom of the dependency tree rather than the top - modules of code can be separated out and request themselves to be scheduled when necessary allowing for much cleaner separation, and more robust code.

For example if your thing is attached to a sensor that spits out 47 bytes of sensor data every N clock cycles, and has a buffer that is 94 bytes, then you damn well better be reading that thing every N*2 clock cycles with a hard guarantee that your routine is finished copying all 94 bytes of data by the time it finishes (including time for interrupts).

This gets complicated when you have specific requirements about when data is available or other things too (e.g. if reading data requires pulling pin X low, waiting at least Y clock cycles, and then reading all data in no more than Z clock cycles before returning pin X back to high, then good luck doing that in a normal OS where you have no hard time guarantees).

One of the things I like about an RTOS is the organization it gives to your code. It gives you primitives like tasks, queues, and semaphores and allows you to easily organize and synchronize independently running tasks. On something like Arduino where you just have a setup() and a loop() function, it can become a mess if you're trying to do many different things with different timing requirements.