Actually, this site switches back and forth between HTTP and HTTPS depending upon the sensitivity of various areas. It is not a perfect setup at this point in time because the built-in nature of vBulletin is an all-or-nothing deal, so there are a lot of server side rewrite rules coupled with custom plugin code to achieve this middle ground.
About the only sensitive thing not presently encrypted (and which I will likely address at some point) is the actual login process. However, your actual password is never really exchanged during login as vBulletin uses a challenge-response method for login, so the two sides are trading hashes that change with each login and it is those changing hashes that actually get transmitted during the login process (provided JavaScript has not been disabled).
However, if you venture to other sensitive areas such as "Private Messages" or editing your profile and other areas where sensitive personal information may typically be exchanged you will find that those areas switch to HTTPS (SSL) encryption to protect your privacy. What we do not bother encrypting are the public areas as they display nothing that is not already available to the general public, so there is nothing particularly sensitive about these areas.
That said, we do not support TLS (where both HTTP and HTTPS reside on the same port), rather we use the traditional SSL strategy of dedicated ports for each, where port 80 is unencrypted traffic and port 443 is SSL encrypted traffic.
Because of the way vBulletin works, if we were to try and encrypt everything then we would have to effectively deny all non-encrypted connections because vBulletin would either by turning HTTPS on at every step or it would be turning it off at every step. To implement the middle ground we currently have takes a good deal of behind the scenes magic to make happen. Part of the argument against encrypting absolutely everything is the increased load on the server and the added latency inherent to SSL connections (which is considerable compared to non-SSL connections). Under normal circumstances our new server could handle the routine load, but it could potentially be brought down (or otherwise refuse further connections) by a poorly implemented spider hitting the server with many thousands of concurrent SSL requests (and there are some very poorly implemented spiders out there), so we have opted for a middle ground that affords greater reliability when faced with such stress while still protecting many of the more sensitive areas. The most critical areas, such as management control panels are 100% encrypted along with additional protections as those are the most sensitive of all areas.