... if your client drops a packet to the server, it creates a larger window where your aim is unaccounted for. This can and does happen, because UDP is an unreliable protocol and is what nearly all game servers run on.
I'm getting tired of people saying or implying that game network programmers are somehow "doing it wrong" by using UDP. What you're saying sounds right because you're using the right jargon, but it's actually totally wrong.
First of all, your game client does not "drop a packet". When packet loss occurs, it is almost certainly occurring somewhere between your computer's network card and Blizzard's edge devices. The packet is dropped by your ISP or an intermediary, or possibly by your network hardware if you have a lot of traffic on your network and bad QoS settings on your router.
Secondly, the protocol has absolutely nothing to do with packet loss. UDP is actually a perfect protocol for game networking, which is why it's used by almost all networked games. The difference between TCP and UDP that you're getting at here is that UDP is correctionless. When packet loss occurs in TCP (and it does happen, due to network conditions completely unrelated to protocol) TCP has an error correction facility for that packet loss, namely retransmitting the packet. The packet is still lost, but in TCP the server has the ability to tell the client that it did not receive a specific packet, and the client will then resend it.
All of the overhead required to make sure that packets are retransmitted when necessary would cause lag. But more importantly, retransmission is worse than useless in a real time scenario like an FPS. Consider the following simplified example:
Now what if packet 2 gets lost and we're using TCP to correct that error via retransmission?