I wholeheartedly disagree. Any content should be delivered over an encrypted channel because any content site can be used to launch an attack on the user os site owner if the data in transit can be tempered with. Passwords and session keys are just a small subset (though admittedly a valuable one) of the stuff you may go after. For example, do you want the FBI putting you on a tracking list because you googled something they consider suspicious just out of curiosity? Do you want a rival of yours messing with how your resume you publish on your personal site is presented to Google or potential employees. Do you want to read man pages that tell you how to run commands over an unauthenticated connection? Do you want Pillsbury to double the amount of their ingredients you need for a chicken pot pie? There is almost no use case where content should remain unprotected.

Apple.com is a great example of this. It's served over plain HTTP, and likes to http://store.apple.com. Can I intercept that link and send you to http[s]?://store.appl.com or http[s]://store.apple.con? I can then grab your credit card. Heck, I could process your order so you won't even know something went wrong. Or how would it look if suddenly people started getting a goatse instead of the latest video of Jony Ivy tilting his head to the side?

Then your issue is with sites that host content on http, and the solution is to address the content hosts—not deprecate a protocol. Besides, If you can MITM http then you can probably do the same for DNS, so https doesn't really solve the attack vector you mention.

Finally, Read this thread for use cases for http. They may not apply for you, but are sufficient that I think we can keep http around for awhile longer.

There are no use cases where HTTP is more capable than HTTPS. There are some hurdles in dropping HTTP, but HTTPS is a strict improvement for almost all cases. The only argument I can see for plain HTTP is legacy devices that no longer receive updates. For these, a UI similar to the self-signed cert warning will work.

My problem is that we still allow plain HTTP. That should never be the case, just like we should not use telnet for remote server access.

DNS hijacking is a problem. It is a problem at a different layer of the system. Just because that layer is vulnerable, does not mean that we should leave a gaping security hole at a different layer. I don't buy the argument that we must have perfect security or no security. Besides, there are ways to mitigate the DNS hijacking issue, such as the HSTS header.