The rules of thumb that I (and other people in the embedded community) use is, if you have some sort of communications protocol going, use an RTOS. If you're doing graphics, use an RTOS.
Once you get a bunch of experience, you'll think "this customer really has no idea of the scope of this project and it's going to balloon in scope really soon now", use an RTOS.
But you could also not use an RTOS, add a feature here, another device there, rebalance the timing due to coupling that wasn't intended, decide that you need just a little bit of a kind of a scheduler looking thing, and suddenly you've written a feature poor RTOS and you say "I should have used an RTOS".
I tend to use an RTOS unless I can see that the project is going to be well bounded, small, and heavily constrained.
The amount of effort that goes into writing code goes exponential with complexity. So if you can break up your code into multiple simple cooperating tasks, you avoid complexity and avoid having your system have exponential effort growth. I've done this by using multiple processors, each running small simple programs. But you get the same effect from using an RTOS. Each task/thread/process is simple, well defined, and small, avoiding ballooning complexity.
Recently I read an article about the software architectures that actually work for multi-processor, high scalability, high performance systems. It pretty much came down to small processes and message passing. Lots and lots of message passing.
So, you can get experience in non-embedded best practices and avoid driving yourself crazy by using RTOS'
