Perhaps my question wasn't sharply/explicitly enough stated, sorry. I'll add the scenario that's bugging me

@GeorgeBailey thanks, I've edited the sentence to read clearer. Sometimes my sed syntax beats my English syntax. :)

@AndréBorie It's nonsense for small scale sites, but when you're getting large amounts of hits, it translates to huge sums of money in these big environments. <sarcasm> That could be added to the CEO's bonus! </sarcasm>

Okay I added the specific scenario to my question which seems to me mindbogglingly cheap and simple.

@symcbean perhaps I should edit my answer to make this more clear, but 3% on a blog site visited by a handful is not a lot, but 3% when you have a few hundred servers is much more significant. I agree though, this is an outdated practice that should be put to rest in favor of TLS-only.

My point is, if I spoof/alter the homepage, then when they click the login link I send them to my server (which will then present itself as the user to the bank) The user I've intercepted never sees the bank's link to the valid https. Just like a phishing attack. So I can't see that I need anything clever at ARP/DNS/SSL level and HSTS is made irrelevant

@symcbean I'm drawing on experience from Credit Suisse and Citibank specifically, and opinions of director level individuals I interfaced with there. No, I don't work at Google or FB or anything like that.

@ChrisFCarroll I'm a bit fuzzy on the details of this attack vector..you're talking about spoofing a landing "splash" page for when users join the WiFi network? Or are you talking about staging a CSRF attack? For HSTS, If you had previously visited the site on that device, HSTS would not allow you to access the HTTP version.

(1) Public Wifi enables MITM straightforwardly (2) As MITM, when you browse to your bank I show you a modified homepage (3) You click on the login link (4) The link is a link to my proxy server which asks for your login details (4 1/2) My proxy server is in the cloud and has a real SSL certificate of its own to show the user (5) My proxy server copies the request to the real login page at the bank but recording the traffic (6) etc. I proxy and record the whole conversation

Yes, I think the wifipineapple is an Evil AP in a box, so I am the access point

Does this mean that the reference to http in my question is a red herring, and that my question is simply, "What's to stop me using an EvilAP to catch bank credentials?"

But no, the http isn't irrelevant. If the user is on SSL all the way from search engine to login page, that's harder to break. If there's an http homepage though, I can serve the user a modified version of that page and have them login to my server instead of the bank's