No, TOTP implementations don’t compensate for clock drift, but they do compensate for moderate inaccuracy and races at the edges of the 30 second slots by typically allowing two or three codes around the current time +/- 1 minute or so.
Well, considering I was part of the implementation team of one of those hardware tokens, I'm sorry I'm going to have to disagree with you :). Please note that I'm not talking about RFC6238 / 4226. I'm talking about proprietary implementations for hardware tokens.
We most definitely had drift management. One of the differentiating features to our competitors is that our algorithm had both a "click counter" (number of times the button was pressed) and a "clock counter". The least significant digit of both counters was included in the OTP that was generated. The authentication server used the last digit of both counters to figure out what values to use, and as you say, generated codes in both time directions in order to try and identify the values of the counters (well, the click counter obviously didn't go both directions).
The server then stored the last matching click counter value and the drift of the clock value. It wasn't uncommon to have tokens that drifted by multiple minutes per month.
This being said, you're right: the clock only incremented every 28 or 32 seconds, not 2.5 seconds as I incorrectly remembered.
