Setting up a TCP 3-way handshake (required generally for TCP) communications would add a lot of overhead to the RIP protocol. UDP is much leaner.
Additionally, the TCP protocol has overhead in the protocol for retransmissions and assured delivery. The assured delivery piece is the CRC, for the most part. But the retransmissions are a part of the 3 way handshake and the TCP/IP protocol's mechanism to retransmit a packet that doesn't get delivered. If ever a TCP packet doesn't get delivered the HARDWARE resends, not the software that originally sent the message. In the case of a Cisco router, the hardware would be the actual router hardware, teh software would be the IOS.
Not only would this overhead for assured delivery be unhelpful for the type of data RIP is sharing amoung it's peers-- it would potentially be harmful due to the inherent retries to deliver the RIP packet to the destination by the hardware. Imagine this scenario, only on a larger scale... sorry, in advance, for the exam type wording.
You are the network administrator a large multinational company with many Dynamic routers on each side of a WAN link that goes across the mediteranean sea (since this link went down recently in the news in several places). you've chosen RIP to be the protocol that dynamically distributes routing information amoung your routers.
Now, if it used TCP instead of UDP, without your being aware the HARDWARE on both sides of the WAN link would continue to send RIP information to the devices on the other side of the WAN link becasue each update did not get delivered, until the TCP timeout expired-- resulting in numerous transmissions on the network wasting bandwidth. This would be compounded when the SOFTWARE tried to send out an additional update at a later time-- resulting in the HARDWARE again attempting a series of retransmissions.
Long story short, the original developers of the RIP (and other dynamic routing protocols) didn't feel the information being sent by the protocol warranted the need for the extra overhead on the (then) slow processors, by today's standards, and the risk of multiple transmissions on the network (likely 4Mb/s or 10Mb/s max for a LAN, and slower for a WAN) that would have been very expensive at the time of development of the protocol.