I've not done any real-time work at all so take this with a grain of salt...
I'm told there's two categories of "real-time": hard real-time and soft real-time.
"Soft real-time" informally means "get it done as fast as possible". I think that Linux on a modern CPU is good for this sort of thing.
"Hard real-time" informally means "get it done within a required time window". The window can be quite small, milliseconds or something. Flight control systems for cruise missiles or satellite launch vehicles seem like the canonical example. Industrial process control systems might also need this. The Stuxnet worm appears to have interferred with systems that do this sort of controlling.
You'd use RTOS in the latter situation. RTOS often guarantee delivering an interrupt in less than so many instructions or clock ticks or whatever.
Another consideration might be that an RTOS is designed, tested and/or "proved" to not consume stack space without bound. It can live inside a certain minimum amount of memory, and things like an "OOM Killer" don't exist because they are provably never needed. Some of the goofier features of early FORTRAN come from this type of requirement. When you compiled a FORTRAN II program, you knew exactly how much stack and how much heap it needed, since you couldn't recurse, and you couldn't dynamically allocate anything.
Realistically, the second consideration (guaranteed max memory consumption) may be more important in some safety-critical applications than "guaranteed interrupt latency of 0.001 seconds".
I would also imagine that stripping the selection process of the fig-leaf of supporting verbiage, you'd find that engineers choose an RTOS because "the requirements say to".