Re: images over HTTPS; most of the attacks involve an active MITM, so it's a question of how seriously you take that threat. Usually, most people ignore this scenario until it gets automated via "coffee shop network attack tools" like firesheep or sslstrip.
Another strike against non HTTPs images is that if you don't have the 'secure' flag set on your cookies, these may get sent with requests, compromising your users' sessions. I guess you could consider not setting this cookie flag as a separate issue. Note that this is a passive threat, exploitable via sniffing.
Thirdly, an active MITM can return any MIME type in response to your <img src> link; you now have to be 100% sure that no browsers will try to process a malicious response of any type when it gets one instead of an image. Probably OK, but are you absolutely 100% sure? What about indefinitely, as browsers implement new features?
Fourthly, think about all the creative ways a malicious user could embed instructions or change the appearance of your site by substituting arbitrary image content. Also note that SVGs can run javascript. One could change an image to be an ad or promotion, for example, to convince the user to carry out an action.
I wouldn't neccesarily follow facebook's lead on security practices.
Modern thinking is that if you care about SSL at all, you should force SSL for everything. For example if your "secure banking site" has an HTTP landing page, an active MITM will just sslstrip the customers and get them to enter their password in the wrong box.
This is why we have HSTS (HTTP Strict Transport Security) header, and why sites that care deeply about security (gmail, paypal, lastpass, etc) use it. (See http://www.chromium.org/sts).