Well, it's also *very* useful when the protocol itself can manage its own retransmissions and/or error control. I've worked on projects where varying amounts of data (like in a game!) need to be sent regularly (read: hundreds to hundreds of thousands of times per hour). In situations like this, even if you need to retransmit every packet several times, you make up for it by sending *updated* information until it gets through. And remember, TCP is retransmitting the information as well, it's just done at a higher level and with more overhead. Trackers benefit from this; They serve information to clients often, clients receive the same information, and clients always want the most current data. UDP is a 'send-and-forget' system, where the server doesn't keep connections open, it just fires off some packets aimed at the client and moves on to the next request. If the receiver gets corrupted or incomplete data, or doesn't receive a timely response, it requests it again. The advantage TCP has is when you want to send a LOT of information that is contiguous and specific to each client/request pair. TCP implementations make sure that all the packets arrive, that they're all in order, and can retransmit individual packets as needed from its buffers. While this seems like a great savings in bandwidth (and it is for lots of things!), it also requires the communications stack to cache outbound data for each of its active connections, and it imposes this (comparatively) massive, continuous two-way conversation between the client and server, and it requires a lot of memory usage and processor time on the server. Hopefully, the UDP tracker protocol is well written (we'll assume this is the case). Client A requests an update (basically, a changelog) by sending a torrent ID with the timestamp from its last checkup. The server finds that there are 4 changes in its log since that time, and sends "{4byteNewTS}+{4byteIP}-{4byteIP}+{4byteIP}*{4byteIP}" back to the client, adding two new IPs, removing a dropout, and converting one peer into a seed, for a total of 24 bytes. With smaller packets like these, overhead is really going to add up. *If there are no changes, you are sending only 4 bytes (timestamp).* TCP uses a 24-byte header per packet (plus 12 more for timestamps, if used), and UDP only 8 (100-150% vs. 33% in our example), plus the client is getting newer information if it needs a retransmit.
