UDP's main advantage is the ability to process out-of-order - by sending duplicate state (actually more wasteful in terms of raw bandwidth!) or allowing for a lossy stream of data, your latency won't spike (as much) waiting for previous packets to be retransmitted. This isn't so much about efficiency per se, so much as it is about minimizing response time (even if it is potentially more bandwidth, potentially more CPU, more code, etc.) which matters a lot for some twitchy competitive games.
It's also not going to have any real impact if you're not dropping packets, nor if you're building your own reliable in-order channels atop that (which even the twitchiest game will likely have for some things if they're not using TCP as well - things like in game chat, leaderboards, matchmaking info, telemetry, etc. - a large number of which might use a full HTTP stack these days, if only under the hood of some official SDK, because why not use the same leaderboard server for your game clients and your website?)
And there's the occasional router (edit: or firewall, or other network appliance) that's so terrible, it manages to ship without a properly tested UDP stack, so a full blown TCP fallback isn't the worst idea ever.
TL;DR: Heckin' trade-offs.
So you would have something like:
Server: state1
Server: state1,state2
Client: ackstate1
Server: state2,state3
And so on.
It's good design, and helped catapult Quake 3 into $billions of revenue. No one had done it quite that way before Carmack. That was long after Quake, however.
