Pierre,
"Why on earth is https with an untrusted certificate less secure than http ?."
Apparently you thought this was a rhetorical question. I disagree. https with an untrusted certificate is less secure than http, because whether or not most users understand the meaning of https, there are a significant number of users who do understand what it means, or at least think they do. You can't seriously tell me you that you think all users always look for the lock icon instead of looking at the URL to know whether they're protected, can you? Users, on the whole, are very good at cargo-culting where technology is concerned. Just because many users look for the icon does /not/ mean that there aren't other users who know just enough of the definition of "protocol" to be a danger to themselves.
An https URL is a declaration on the part of the server (or the party linking to it) that the resource in question should be secure. This creates an expectation on the part of those users who know what https is that if the connection succeeds, it is secure, which means they'll think it's ok to do the kinds of things that they normally do over secure connections but won't do over unsecured ones.
It therefore certainly is important to give users feedback that an https connection has failed. If you try to connect to an https resource, and your browser can't verify the certificate, something is wrong. Either the server operator is a stooge for Intel trying to drive up the client CPU requirements for web connectivity so that they can sell more chips, or the server operator has failed to establish a chain of trust to you in the appropriate manner, or someone really has compromised the connection with a man-in-the-middle attack. Any of these conditions are something that ought to be brought to the user's attention, not ignored.
If you don't like seeing cumbersome security warnings for insecure https connections, how about not using https when what you really want is http in the first place?