When busy with a factory test or similar, it's enough for me to be able to dump 16 channels times 16 samples and to also be able to see some statistics about the data (average and standard deviation for the channels). It really is lovely to be able to change the supply voltage to a device and see what voltages (and how much noise) the firmware thinks it sees. Or to be able to toggle a relay or see how many satellites the GPS is seeing. Maybe read the firmware version in the GPS or GSM module.

A serial port may have limited bandwidth but then it's just a question of figuring out what information that is important.

You may have a serial protocol that is only able to send back "error" in case the message is too large or malformed. With a permanent printout facility, you could have the firmware print that parameter 3 of the protocol data was out-of-range - suddenly much easier to inform the customer that the unit is working as expected but the customer is doing something wrong. And you can prove it by mentioning the incorrect value of the parameter and the paragraph in the protocol standard that says what the allowed range should have been.

For factory testing, it's nice if the factory test jig can interface with the microcontroller and have the microcontroller perform actions that the test jig verifies - or have the test jig send stimuli and have the microcontroller ackowledge that it correctly reads the stimuli.

So there are a number of reasons why it is useful to have some form of test interface in the software. But then it follows quite naturally to use the same interface for having some trace printouts - some permanently accessible and some added temporarily during debugging of a specific problem.