Why Does RTP use UDP instead of TCP?

As DJ pointed out, TCP is about getting a reliable data stream, and will slow down transmission, and re-transmit corrupted packets, in order to achieve that.

UDP does not care about reliability of the communication, and will not slow down or re-transmit data.

If your application needs a reliable data stream, for example, to retrieve a file from a webserver, you choose TCP.

If your application doesn't care about corrupted or lost packets, and you don't need to incur the additional overhead to provide the additional reliability, you can choose UDP instead.

VOIP is not significantly improved by reliable packet transmission, and in fact, in some cases things in TCP like retransmission and exponential backoff can actually hurt VOIP quality. Therefore, UDP was a better choice.

A lot of good answers have been given, but I'd like to point one thing out explicitly:

Basically a complete data stream is a nice thing to have for real-time audio/video, but its not strictly necessary (as others have pointed out):

The important fact is that some data that arrives too late is worthless. What good is the missing data for a frame that should have been displayed a second ago?

If you were to use TCP (which also guarantees the correct order of all data), then you wouldn't be able to get to the more up-to-date data until the old one is transmitted correctly. This is doubly bad: you have to wait for the re-transmission of the old data and the new data (which is now delayed) will probably be just as worthless.

So RTP does some kind of best-effort transmission in that it tries to transfer all available data in time, but doesn't attempt to re-transmit data that was lost/corrupted during the transfer (*). It just goes on with life and hopes that the more important current data gets there correctly.

(*) actually I don't know the specifics of RTP. Maybe it does try to re-transmit, but if it does then it won't be as aggressive as TCP is (which won't ever accept any lost data).