So I notice the UART (including USB) is NOT buffered. Does this mean that sending data out of UART or USB is CPU-intensive as it bit-bangs the communication manually? There must be some waiting in-between bits.

Can the RTOS otherwise use this downtime during printf functions to perform other functions?

The UARTs are implemented in hardware. No bit-banging necessary. The cpu (ie your code) can just drop a byte and move on. The hardware will take care of the 'slow' serial transport. There is actually a short (16 byte) buffer inside the UART to store some bytes which help to avoid waiting around for the UART to finish. When you need to send larger packets you either have to wait until the UART is empty or you have to use a software interrupt approach. There is a MODSERIAL lib available that will do that. Check http://mbed.org/cookbook/MODSERIAL

UARTs (most) have a 16 byte FIFO in hardware. But the OS must enable and use the FIFO. On top of that, any decent OS driver has ring buffers. But a program doing lots of printf's will block if the buffers and/or FIFOs fill. The cure to this is to configure stdout to use your own wrapper on I/O calls so you can do non-blocking output. Or use sprintf to a buffer and have a task of your design to copy the sprintf buffer to some other buffer and do parallel non-blocking output - from a different task, using RTOS message queues or some such - assuming those buffers are large enough.

So each byte (or 16 bits) are buffered in hardware, and the software waits until the UART is ready for more bytes. If using the standard printf command under RTOS, will this waiting be locked, or will RTOS find something else to do?

Since the mbed RTOS is rather new, I'm having a difficult time getting multi-threaded routines working.