Why does TLS require TCP?
TLS requires a reliable transport. On the internet, this leaves only TCP, as UDP does not offer reliability.
TLS does require a reliable transport because (in compliance with the layered architecture of the ISO/OSI reference model) it does not handle transport errors, lost packets or other disturbances that may occur with IP.
TLS is designed to offer a secure channel on top of a reliable transport and it does this quite well. DTLS does (I assume) the necessary error handling within the protocol.
If TLS was to be performed over UDP, connections and handshakes could fail just because a packet got lost in transit and no one noticed.
Mitigation of such problems is (according to the ISO/OSI reference model) the designated task of a reliable transport. Any reliable transport works theoretically, yet for all practical purposes of IP networks, this usually implies TCP.
TLS does not require TCP, it only requires a reliable transport. There is even a standard for TLS over SCTP which is another reliable transport protocol.
But, if you take today's internet then you usually only have UDP and TCP as transport protocols on top of IP and from these two TCP is the only reliable one. Which means, if you have only this limited selection of transport protocols available then TLS requires TCP because it does not work with UDP. To work with UDP there is a similar protocol DTLS which is designed to work over unreliable transports.
In addition to what others have already said, TLS requires a reliable transport layer protocol because it requires that all of the data packets be received, be received in order, and be received uncorrupted. There are several reasons for this:
If a packet were dropped or corrupted, TLS would have no way of recovering the data from that packet to present to the application layer and, thus, the assumption of reliability presented to the application layer would be lost.
If a packet were corrupted, even by a single bit, it would likely be completely garbled due to the encryption, particularly if a block cipher is in use.
If a packet were lost, corrupted, or processed out-of-order, any encryption scheme based on Cipher Block Chaining would not only fail to decrypt the current block, but would also fail for every block after it, since each block depends on the block before it (and, thus, on all previous blocks.) Thus, any packet error on the network at all would require the TLS connection to be torn down and renegotiated. Cipher block chaining XORs the plaintext for a cipher block with the ciphertext of the previous block prior to encrypting it in order to prevent someone monitoring the ciphertext from being able to detect patterns of duplicate plaintexts from the ciphertext.
If a record were corrupted, even by a single bit, the Message Authentication Code would not match, causing TLS to (correctly) think that the message had been altered in transit, which would result in the TLS connection being torn down.
If a record were received out-of-order while a stream cipher were in use, the portion of the message in that record would be decrypted incorrectly (using the wrong portion of the stream) and, thus, the MAC check would fail and the TLS connection would be torn down.
Of course, TLS itself will work fine as long as the underlying transport protocol provides the guarantee of reliability. There's nothing within TLS itself requiring the underlying transport protocol to be TCP. Of course, TCP is generally the reliable protocol of choice where the Internet is concerned.