Years ago, I was DBA for a system that was replicating from USA to China (many years ago). An earthquake happened in the Pacific, disrupting most traffic to/from east Asia. Connections were flaky for most of a day, by which time traffic had been rerouted (I guess) through the Suez Canal instead of the Pacific Ocean. Slave connections came and went, but MySQL replication survived.
"UDP is faster" -- I suggest that this is an 'uninformed' reason. MySQL uses TCP/IP because it needs to know that the packets arrive at the other end. With UDP, replication can break due to network issues, and MySQL would not know it. That leads to a much worse mess than being "slower".
CH:CN might be about 250ms -- that is network travel time. One packet will take that long, whether you are using TCP/IP or UDP. TCP/IP will seem slower because it will send only a certain number of packets before waiting for ACK/NAK. That can (and should) probably be tuned due to the long distance.
Once you have done that low level tuning (at the OS, not MySQL), TCP/IP will be about as fast as UDP. But reliability is the real reason to tell your client to jump in a lake. (Sorry, I don't know the OS tunables.)
As for Replication being "down for a long time"... (I assume you mean hours or days.) Yes, you should plan for such. Set expire_logs_days to a high enough number. I like 14; that's days.) Plus have monitoring to see if things have gone bad. UDP can't help with the network being down.