That being said the second part of your argument is completely wrong. You can just as easily inject evil JS using an https server and never get the mixed content warnings.
The warning serves to indicate to users that some assets (think important-financial-graph.jpg) aren't being served over the same encryption as the rest of the page. But then again, browsers like Safari have no problem with this. Other browsers like Firefox (correctly) cache these assets on disk if Cache-Control:public is set, thereby un-encrypting the asset.
The error may not be spurious, but it sure doesn't mean the page is secure or not.
Only if the user ignores the "invalid certificate" warning.
2. hot-new-metrics-startup gets hacked. Sends over malicious js
3. Your page is no longer secure. https certificate remains.
We can argue semantics, but I guess I'm more concerned about the end result than semantics.
It certainly might be possible for the attacker to compromise a specific server that you have chosen to trust - but that's a much higher barrier to an attacker than performing MITM on an open Wifi connection which doesn't require them to compromise any server.
1. You include http://google.com/trusted.js on a https page
2. Someone goes to a cafe, opens up your website with Safari while someone is performing a MiTM attack on that file.
3. No warnings, your user is compromised.
EDIT: I do take your point in that I think IE is the only browser that actually blocks the content. The others warn about it but still load it, by which time, of course, the damage is done.
What is the purpose of warning more prominently in the scenario described, than in the scenario where the user goes to a non-SSL site in the first page, or is redirected from an SSL login form to a non-SSL page?
If you don't trust a company and their competency at security you probably shouldn't be using their service for anything sensitive. You can't assume that your users aren't on hostile networks vulnerable to MITM attacks, etc.
The mixed content warning helps to warn the developer of the site of the problem, and let users of browsers that support it know that they are not fully protected.
Hint: People sell out-of-the-box solutions to the problem.
It's trivial to get certs that browsers won't choke on. You have to more than check for the cert not being "invalid", you have to actually examine it carefully, knowing which cert sellers are trustworthy and which are not. Your SSL lock icon is useless.