Theope, UDP and TCP are very different TCP/IP transport protocols. TCP is a connection oriented transport protocol that can recover lost or corrupted data that occur anywhere between the peer session stacks and UDP is connectionless that in itself is fire and forget and has no way of recovering lost or corrupted data. There is also RUDP but I have never seen that used in home audio so we will ignore.
Now the key aspect in the above is the latency of the stream - if the relationship between latency (delay), bandwidth and segment memory permits TCP can recover lost data in the stream. This can be seamless if the resent packet is received before the segment buffer is exhausted, if not there is a loss of data and interruption (audio drop out or video pixelation). If the link has relatively high latency between peers then it will be less robust at recovering lost data for a given throughput and segment buffer size. When the receive TCP segment buffers are full the correctly received segment buffer is assembled and is passed up to the application. This is why there is a delay or latency.
With UDP as it connectionless and there is no confirmation - the UDP datagram pass across and up the to the application stack - bypassing windows and receive segment buffers. UDP is for low latency but at the cost of robustness or reliability. In our home audio cloud streaming and UPnP, TCP, not UDP is used for media transfers. UDP is used for signalling and discovery⊠where is loss of a datagram is not a big issue - other than a small performance hiccup.
You mention jitter to the signal - jitter is not meaningful in TCP as the flow can be very un even and even can be un ordered.
UDP can have jitter at the datagram level - where the UDPs datagrams are sent with precise timing - as per carrier grade Voice over IP. But the jitter is for blocks of data rather than sample values.
If you are thinking of sample based jitter - then this is meaningless in these examples, as essentially with TCP a file is being transferred, and with UDP mini file components are being transferred.
Jitter is meaningful when you have a data stream where one of the values sent is time and the other is the sample value. However as the network protocols we are discussing transfer media files or parts of files this is a different paradigm and jitter in this context is meaningless.
Now finally - with respect to the reliability of networks as per my post you referenced⊠ethernet including home ethernet is inherently reliable, however host protocol stacks are less so as they are dependent on CPU, I/O and other local system type resources. in some scenarios these can fail to send or receive data when very busy - and so TCP steps in and attempts the recovery of data that was lost by the peer due to temporary lack of resources or bandwidth. This is a far more common use of TCP data recovery in home networks than data corruption or loss on ethernet in my experience.
With internet access it can be more balanced between network and receiving network stack⊠but TCP is busier on internet accesses where there is higher round trip latency.