Reliability is the key. Timing requirements make retransmission back-off problematic, as it can trigger PSTN timers. BGP peers exchange large messages, requiring some form of segmentation. Because BGP maintains synchronization from startup through shutdown, and long-term associations, it's natural to introduce connections as opposed to datagrams. The utility function is smooth with bandwidth degradation, so TCP congestion semantics are okay.
Updates are self-describing, so no sequential ordering or duplicate detection is needed.
All told, though, going with TCP was a win, because it saved significant development effort, and its deficiencies in retrospect were not that grievous. After Dave's presentation, further discussion was solicited from the floor. Furthermore, DNS queries are growing in size, increasing the problem of needing fragmentation for a very widely used protocol. This is really more a control problem than a transport problem per se - an application might decide what to do differently based on information from transport. E.g., if a routing update fails, send out different information rather than just a retransmission.