Just want to put this out there, I am developing a client-server 2D TCP networked game, I tried connecting to my game server (hosted at my home) on my laptop though my phones WiFi hotspot (I was further out in the country at the time aswell). That version's build had liquid animation that was compressed -> It ended up running pretty well and latency was within 200ms and this is a game that is not developed for internet through the phone.
It would be pointless to use UDP if your going to just reimplement TCP. If some packets can be dropped and/or you want a custom error detection design other than the way TCP handles it then UDP would make more sense, otherwise in my opinion TCP saves time and is optimized well.
Well, for my gameplay I think the lag in TCP when moving is sufficiently annoying to detract from the gameplay. Opportunities in my case for predictively animating responses is minimal, so I'm willing to try anything that can reduce the latency.
I agree that it's meaningless to implement reliable UDP for a game like this. However, given that my packets are typically on the order of a few tens of bytes, I have more opportunities with UDP. More specifically I can keep resending the all the non-acked data until I receive an ack for them. That way I don't need any ack-timeouts (which is what TCP and many "reliable UDP"-solutions are using).