Sorry for my very late reply. Life intrudes.
For an platform of modest capabilities like the Arduino Uno that uses the 328P, I think an RTOS is probably overkill, and difficult to boot because of the memory constraints. You spend all your time agonizing over how big the stack for each task needs to be.
On the Arduino Mega that uses the 2560, it's completely doable and reasonably painless. But is it necessary?
There are a lot of applications that, for reasons of functionality or performance, really gain from [1] interrupt driven device drivers, and [2] multithreading as a fundamental mechanism to talk to the device drivers. Not only is it a more useful architecture, but the ability to separate functionality behind a more opaque interface, saves money in the long run (in terms of commercial development). Plus, it's a very useful teaching platform, since this approach is used a lot in the commercial world on 2560-class processors and above.
On the flip side, I'm in the midst of a paying gig in which I'm writing firmware for several products based on a PIC16F1823 microcontroller, which has a scant 2K of program memory (flash) and 96 bytes (that's bytes, not KB) of RAM. I'm writing in C, and I've developed as many as six interrupt driven device drivers on one of the products. But there's no RTOS, nor is there really space to have such a thing. It's just a task loop. So i think it totally depends on the problem you're trying to solve and the resources at your disposal. A colleague is developing for a larger PIC on a related project, and he is in fact using FreeRTOS and multitasking so that he can do slower, non-real-time tasks in the background.
At the higher end of the embedded realm, which in my work typically involves PowerPC and ARM SoCs, it's all over the map, using OSes (not necessarily RT) like CMX, C-Executive, Simple Executive, VxWorks, the late pSOS, and even a stripped down Linux. These range from very simple to extremely complex in terms of API, use model, capability, etc.