For the first use case, using HTTPS, whether it be self signed, expired, bad domain, or whatever the failure mode, is strictly better than using HTTP. It's that simple, because you're providing a layer that does not exist otherwise. Hell, at least if you're getting MITMed, it's you vs the one attacker, not you vs the government and every other kiddie with a copy of wireshark.
For the second one, we care a lot more about the authentication bit.
and an expired certificate is still invalid.
..for no good reason whatsoever. If renewing a cert required a rekey, that would be one thing, but it does not. If an attacker has compromised your private key, nothing is stopping them from going out to your CA with a fresh CSR in hand and regenning the cert themselves! The functional difference between an expired cert and a non expired one is how loud the browser whines about it - you're just as secure, identity has still been verified to the same degree. It's arbitrary and pointless and bureaucratic and causes more problems that it solves, and needs to go away.
if I'm an issuer of certificates I would expect that if I said a certificate I issued is expired, it would be treated as such.
If you're an issuer of certificates, you have a vested interest in making the process to become a competitor of yours as annoying and expensive as possible. (How'd that ~$30k WebTrust audit work out for some of the CA's recently?) You also have no differentiation in product - once you're an accepted CA, your cert is as good as VeriSign's and provides absolutely nothing that theirs does not.
What this means is that the vendors trade on fear, much like antivirus companies used to (and kind of still do) - creating this bogus perception that a signed SSL cert is anything other than a signed SSL cert depending on who you paid and how much.
