How risky is it not to install ssl?
Without SSL, all that is sent over the wires can potentially be spied upon or altered by indelicate routers. "Altered" includes hostile hijacking of connections and Man-in-the-Middle attacks. These are relatively easy to setup by attackers in the context of WiFi hotspots -- which means that if a user is accessing your Web site from a restaurant or a public park (using his laptop or tablet) then his data (in particular passwords and cookies) can be silently eavesdropped by ill-intentioned people equipped with a readily available 100$ gadget.
Moreover, not only are non-SSL connections easily commandeered by hostile outsiders, but people begin to know it. When your users see that you use passwords without SSL, some of them will think that "you do not care about their security". That alone is not a good thing. You want your users to feel safe, otherwise they'll be tempted not to be your users anymore.
SSL costs are routinely exaggerated, for reasons which are not completely clear (there is some theory on the subject):
On the server: the extra CPU and network overhead implied by SSL is in the 2% range, i.e. not a lot. Biggest indirect cost is that SSL prevents some transparent proxies (run by some ISP) from doing their optimization; it might have some impact if your server hosts big static files. The cost of the certificate can be zero -- or, more accurately, no buying fee, and some administrative task once a year. Even in commercial contexts, the cost of the certificate is negligible with regards to the hosting costs and sysadmin time.
On the client: the main effect is increased latency for the very first connection. When opening the first connection, client and server run the full TLS handshake. But the connection will be kept open for subsequent HTTP requests (the normal "keep alive" mechanism), and if the connection is closed due to prolonged inactivity, new connections will use the abbreviated handshake which reuses the cryptographic elements from the previous connection. the abbreviated handshake is much faster, especially since it implies one less network round-trip.
Nothing beats actual measure, so you are encouraged to experiment, if only with a homemade certificate (aka "self-signed"); but, on the whole, SSL cannot be considered as really expensive (it used to be expensive, 15 years ago, but computers have grown a bit in computational power since these times).
Without SSL, it will be trivial to takeover user accounts through a MITM attack. All the usernames and passwords are sent over in cleartext, making it really easy to sniff. This has a rather severe indirect consequences if users reuse the same username/password combination across multiple sites.
There are plenty of other attacks if SSL is not activated, but I feel this is simple and severe enough to illustrate the point.
A more indirect effect of SSL (or a valid SSL certificate rather), is that the padlock on the browser inspires confidence in users. It is rather difficult to explain to non-technical users the reasons for SSL. It is slightly easier to train them to associate the green padlock with a secure site. Not have the same padlock might lead to users questioning(rightly), the security of your site.
If cost is an issue, there are quite a few free SSL cert providers, such as StartSSL. Do note that I have never tried their services before so I am unable to vouch for their reliability.
Without SSL, users' data is transmitted over the wire unencrypted. Is that an acceptable risk?
Everyone here is using a discussion forum that does not use SSL (and SE is not unique in this regard; e.g., reddit doesn't use SSL)1.2017 EDIT: stackexchange and reddit now both use SSL unlike when this answer was written in 2013
A network eavesdropper between my computer and stackexchange's servers (e.g., other users of the same wifi access point, or at my ISP, or network administrators at my work) could steal my authentication cookies or alter my messages and get full access to my stackexchange account. I'd rather that not happen, so I don't use stackexchange on public wifi and trust my ISP to not steal and misuse users' secret information.
Granted, this is a risk I'm willing to take. While someone capturing my stackexchange account (temporarily until my session cookies expire), they wouldn't capture much information and most of their actions could be later undone (e.g., any edits can be reverted).
Also, don't equate SSL on VPS with full privacy. You still must inherently trust your VPS host, which can easily grab your private SSL certificate from your VM (its on a file on their disk) and then decrypt all your incoming traffic. I doubt most reputable VPS providers would do that, but they definitely could.
1Well stackexchange let's you authenticate through an OpenID provider like google/facebook/yahoo/etc, and those providers will use an https connection (at least everyone I checked) so the password is sent encrypted. They do have a "login with stackexchange" option which directs you to a http page that uses javascript, so the form submission with the password should be transmitted encrypted (using SSL). Granted, it would be trivial to launch a MitM attack on this, as the https connection is not readily apparent to the user. And again, while the attacker cannot grab your password, they can later grab the session cookie so they will appear as an authenticated version of you.
Similarly for reddit.com, they (secretly) use SSL for the form action, but as the form is hosted on a non-ssl page it is easy for an attacker to launch a MitM attack and capture your password. Granted reddit.com does have an SSL version with a properly signed CA, but this site is not on their CDN and is only meant to be used by advertisers/people making credit card transactions at the moment.