If you pointed out that trojans and spyware are a much larger threat to one’s credit card than any man-in-the-middle attacker, I’d have been the first one to agree.

That doesn’t change anything about the flawed principle I pointed out. Every weakness is exploited at some point.

If you serve a login box over plain HTTP and post the data to HTTPS (as java.net in fact does), a man-in-the-middle attacker can simply redirect the HTML form and intercept your password; this is not much more difficult than intercepting a password sent back over plain HTTP. How many end-users are so vigilant as to check the action string of every form they post?

In other words: you can’t send a login form over plain HTTP.

There are three alternatives at this point:
1) simply forget it and log in over plain HTTP
2) serve the entire homepage over HTTPS
3) serve a secure login form in an iframe

Option 1 is very bad form for a company that has your creditcard number. I wouldn’t want to do business over such a site, and I don’t think you would either.

Option 2 is a scalability disaster.

Option 3 puts an (unacceptable) hit on accessibility.

As inconvienent as an extra page may be, it is a necessity (but of course no guarantee) for a secure login procedure that does not involve sending the entire homepage over HTTPS.