The single problem with TCP this rightly points out is head-of-line blocking. But overcoming that still leaves you with the problem of coping with out of order or missing events at app level, with clients and servers seeing events in differing sequences (fex packet sequence of move-duck-fire, now shuffle the move around...). I witnessed one game engine project implement custom networking on UDP and then disable unreliable & out of order messages because of game logic headaches.
And the payoff is quite small, since packet loss is rare in healthy networks and TCP handles the rare loss pretty efficiently based on ack clocking, not timeouts (fast retransmit, basically same as his idea of "redundantly sending un-acked data").
How many networks are actually healthy, though? Networked gaming is less about a hardwired LAN and more about reliably synchronizing state using your crap wifi in a oversaturated band when Comcast hasn't repaired the infrastructure I your neighborhood in years.
In other words, a healthy network is the edge case.
Sure there are people with rotten last mile conditions, but healthy networks are the normal case. You get subpar download speeds with http and choppy skype/facetime/ssh if your network drops packets frequently. It's bad for business from the ISP POV. Using UDP will not work around the conditions you describe, game will still be laggy and choppy.
Downloads will work just fine if you're dropping .1% of packets. Skype is very resilient to dropped packets. Console use isn't quite so fast that a half-second hiccup is a big problem.
But a naive game implementation over TCP will stutter badly and obviously every time.
Yep, and that's different from the hopelessly choppy last mile. The question here is if there's a big difference between a good (not naive) implementation over TCP vs various DIY UDP schemes, and whether that difference justifies the big complexity increases in game design due to trying to cope with out of order/lost events.
You can only do so much over TCP. Unless you are willing to put in a significant delay, dropped packets will cause problems. You can hide them, but there will still be shots that miss, enemies that were never where they displayed, etc.
And the payoff is quite small, since packet loss is rare in healthy networks and TCP handles the rare loss pretty efficiently based on ack clocking, not timeouts (fast retransmit, basically same as his idea of "redundantly sending un-acked data").