counter to indicate hotp count 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?
Your question starts from an assumption that often isn't valid.  You write:


  Assuming the user didn't have to input the OTP value or counter number


but in fact, for cost reasons, often these devices don't haven't any way to send the counter number to the server; the user would have to input it.

If the counter value is actually based upon the time, so it doesn't need to be sent, then yes, the quote from Thomas Pornin doesn't apply.  For those kinds of tokens, yes, the server can use the time and we don't have the issue with it getting desynchronized if you press the button 100 times.  The server does still need to make sure that the token's time approximately matches the server's time, and that the number only increases (to avoid replay attacks).