I was trying to figure out how HOTP kept from wrapping over, when I saw this explanation of how it works, by Thomas Pornin [source]:
The intended scenario is the following: the client has a handheld device which outputs the successive passwords, one new password per button-press. The client may press the button a few times between two login attempts. The server "bets" that the client will not press the button more than, say, 100 times before attempting to log in again: so the server uses $w \leq100$. If you let your 3-year-old nephew play with your HOTP device a whole afternoon, chances are that it will be too much desynchronized, and login will not work any longer.
Assuming the user didn't have to input the OTP value or counter number(lets assume its something akin to a yubikey), what would be the downside of having the device feed the site with what the counter number is on, before giving the resulting OTP to check against?