As I alluded to in a comment here, one reason that we can't expect people to understand that 'low quality encryption' is basically 'no encryption' is that browsers don't. In fact the issue shows why having a distinct and specially marked 'https' is ultimately a terrible mistake; it has trained programmers and users that https means security, when in fact it doesn't.

What would have been much better is if browsers hid the difference between the raw protocol being used and instead showed an indicator of the degree of security involved. This would have had two beneficial effects. First, it makes it much easier to deploy opportunistic encryption to foil passive eavesdroppers, since you are not telling people that the use of SSL means that they are secure (instead you are hiding that SSL is in use). Second, it lets browsers only mark things as secure if you are using SSL parameters and certificates that are actually secure, not just if you are using SSL at all.

Okay, it would also have a very important third effect: it would have at least tried to communicate to users the thing that is actually important, that being the security of your connection. Using SSL is merely a necessary prerequisite to actual security and so the current situation tells users about an implementation detail.

(Thus it is not a surprise to me that current browsers tend to de-emphasize the whole 'you are using SSL' business. Sadly this is too late in practice; people's expectations are too solidly set by now.)

Transparently attempting SSL without slowing things down has a number of technical issues, but there is a deeper reason why it wasn't really possible to do this back in the dawn of the web when SSL was being introduced. The simple summary is cryptography export controls. Back in the days, US companies were not allowed to export products with actual secure cryptography, only ones with aggressively weak keys. In a theoretical world where browser vendors are turning address bars yellow because of security instead of SSL, this presents the browser vendors with the serious issue of how to show this to users.

The honest approach is to not mark these weak ciphers as secure in any version of the browser. This is unpopular with the purchasers of SSL certificates, who are after all paying money in order to have people's address bars turn yellow; it is especially unpopular with non-US server operators, whose servers only did insecure key lengths and so would never get yellow address bars no matter what SSL certificates they bought.

The 'as secure as possible' approach is to mark these weak ciphers as secure only in the international version of the browser. Now you have a confusing user experience; the same website using the same SSL will be shown as insecure in one browser and secure in another. (This too is not so popular with non-US SSL server operators, who will never be shown as secure to US users.)

(Always marking these weak ciphers as secure even in domestic browsers makes a joke of your claim to be turning the address bar yellow only when the connection really is secure.)

Turning address bars yellow on SSL instead of security has the great advantage of avoiding all of this. You have a simple rule and your international and domestic browser versions behave the same on all SSL-supporting websites.

(PS: I'm sure that the technical issues alone were more than enough to sink the whole idea of transparent SSL back when it could have been introduced.)