Why is the TCP scan much faster than the UDP scan?

TCP is a connection-oriented protocol. This means that systems must establish and confirm a stable connection for TCP, the process is commonly known as the “three-way handshake” — before actually sending the data. In the case of TCP, it utilizes a half-open scanning technique that sends an SYN packet and is waiting for the response. If it receives SYN-ACK, it means the port is open, but if it retrieves RST-ACK, it means the port is closed. As the process must happen quickly for a good connection, it can be reasonably expected that an open TCP port will respond in short order when it is probed. This means that the timeout before assuming a port is closed may also be very short. It could also be seen that the TCP scanning duration is too shorter rather than the UDP port scanning duration because the sender machine would be received port status from the target machine rapidly.
And scanning each port has been done just once. On the other hand, UDP is a connection-less protocol. NMAP UDP scans will take some time to scan because, For scanning by UDP message, NMAP would use ICMP messages to discover port status. If a UDP packet is sent to a port that is not open, the system will respond with an ICMP port unreachable message. Still, Neither UDP packets nor the ICMP errors are guaranteed to arrive, so UDP scanners of this sort must also implement retransmission of packets that appear to be lost or filtered. Ports rarely send any response; this leaves NMAP to time-out and then retry transmissions just if the probe or scan was lost. NMAP would detect the limitation rate, and it would be slowed down the scanning due to avoid flooding the network with useless packets which target machine will drop. So the scanning host H1 must wait for the ICMP error messages related to each of the 100 scanned ports, and the rate at which those messages are generated is about 1 per second. Every port may check several times.