Quiet network
no competing traffic, all the bandwidth is yours to use
Congestion
traffic > hardware allows. TCP will automatically detect that it's losing too many packets and slow way down to try and let the congestion clear up (in the case of a game it's likely the user would rather the game not be the application that sacrifices connection speed). On the other hand some routers have been known to discard udp packets to relieve congestion since they aren't guaranteed to arrive anyways.
How often will TCP waste time re-transmitting in a general case, or even a specific case?
Forever - TCP ensures all packets arrive in the correct order. If the client sent packets 1, 2, 3, 4, 5 and the server received 1, 2, 4, 5 it'll give 1 and 2 to the application, but hold on to 4 and 5 until it receives 3. In practice 3 should arrive shortly after as if the connection is so bad that you never get 3 it's unlikely you'll get 6 when it's time either, but you're still stuck waiting whatever the tcp timeout for 3 is plus the retransmit time 3.
As for the drop rate in the wild I won't even try hazarding a guess, maybe it's so infrequent as to not really be worth concern, but for a particular drop the resend implies at least a retransmit timeout + transmission time delay which may or may not be a problem.
Potentially off topic
Going back to the tcp packet loss example - in latency critical games (like the shooter example people keep providing) it doesn't really matter if you get 3 or not as by the time the server receives 3 it's already done calculating that "tick" and the information contained within would be too old to use.
As an example let's say that player A lines up a shot at another player B and pulls the trigger. The client sends this information to the server and it gets lost in transit. Since the server doesn't realize player A fired it validates the current tick and player B is still alive. A moment later the server receives the "fire" packet. Should the server