This approach is necessary if you have no hardware assistance, so the CPU indeed needs to wait for each byte. But often you do have some sort of a FIFO (sometimes even a DMA) to offload transmission to a peripheral.

If you do have such hardware, you could use another “hybrid” approach which is to poll the peripheral from a periodic interrupt. Please note that I don’t mean here interrupting for every single byte, which is highly inefficient and often inferior to simple polling.

For example, a UART with a 16-byte FIFO transmitting at the high rate of 115200 baud needs CPU to reload the FIFO only every 1.38 ms. So if you interrupt every 1.2-1.3 ms (~800 Hz), you can keep the FIFO constantly full. An interrupt rate of 800Hz is high, but manageable (as opposed to interrupting at 12kHz for every single byte, which is highly inefficient).

My point is that one should avoid if only possible tying up the CPU completely for longer periods of time. Such design is not only inefficient in terms of power consumption, but more importantly makes the system unresponsive. Too often software developers fall for this, instead of using existing hardware (such as FIFOs) or insisting that the hardware team provide an event-driven support (e.g., through an FPGA).