He's right--you're just not talking about the same thing. You're saying that if somebody forges a non-HTTPS page so that it doesn't POST to the original secure page, then you can trivially intercept the credentials, and you're absolutely right. But pietro is also correct that if a non-HTTPS page that POSTs to a HTTPS page isn't manipulated, then yes, the POST contents will be encrypted--but the fact that that doesn't matter if you can manipulate the connection is clearly a problem, one HSTS is intended to alleviate.
Except if the HSTS cache is not present for whatever reason (reinstalled OS, new browser, cleared browser cache, or just a first-time visit). Rather unlikely usually, but HSTS is not the ultimate solution to this. People should type https manually or know exactly what to look for (padlock; don't mistake paypal.com.index.php.session.longhexcode.tk for paypal; mixed content; etc.) if they want to be absolutely positive the connection is secure.
That's why I said alleviate, not solve. HSTS is a bandaid at best.
The bottom line is regular people don't know the difference between entering "www.mybank.com" or "https://www.mybank.com", they never do the latter, and they rarely notice if a page is non-HTTPS if it has other icons that make it seem secure (e.g. "McAfee protected")--hence the reason sslstrip exists in the first place.
