I don't understand it, but it definitely happens. So, maybe the folks who are choosing to save passwords in plain text are accepting the tradeoff in order to avoid having to answer as many support emails.

We actually save plain text passwords within our management apps for a few circumstances; but not for emailing to users and never on world-facing web applications. We offer the user the ability to use passwords in place of SSH keys for hooking up to managed systems in our cloud computing management product and in our cluster modules (though we generally recommend keys and SSL certificates); we also store MySQL passwords on behalf of users so they can manage their own databases from the control panel (this is akin to having MySQL passwords stored in configuration files for web apps, though it's a bit safer since only root can read them directly from the file system). Our webmail client stores user passwords for authenticating to IMAP/POP3 services (much like Thunderbird or Outlook do, only we do it server-side). So, it isn't "benefits" per se, in our case, it's that there's functionality that users want that can be done no other way. They could be two-way hashed, but if an attacker has obtained root, they would have access to the key needed to decrypt the hashed passwords, anyway, so it seems pretty silly to pretend like something is encrypted if the attacks needed to be able to access the plain text would also grant access to the keys for decrypting.

I get the feeling password encryption is a feature that's mostly implemented as appeasement (if you do send passwords in clear, every once in a while you will get someone mailing you about it, and most of those people have blogs so you can't brush them off or ignore them, unless you like negative publicity).

Not unless you want to use your users' passwords to impersonate them on other sites... or to allow anyone who breaks into your servers to do the same.

Don't use MD5 either -- that's far too weak. Use a real key derivation function: Ideally scrypt, but failing that, bcrypt or PBKDF2.

Conversely, just because they email you a password reset link, doesn't mean they encrypt your password. It could still be stored in plain text.

"Development" doesn't exist in isolation. You can't look at just the "development benefits", you have to look at the "product benefits".

The product benefit of storing a password with reversible encryption is obvious: a simplified "forgot password" feature. If your users are all hardcore geeks, that's not much use, but if you have many users who are not very tech-savvy, that can make a pretty big difference. After all, if a user can't figure out how to log on to the site because they are too confused to use the reset password link, you've lost that user - and for all you know, maybe that user is a 60-year-old director at a potentially huge client of yours, who then will decide not to bother with your product because he can't log in.

The question you might also ask, perhaps, is whether there is a real security benefit to you if the site you're using does encrypt your password non-reversibly. Assuming that the people running the site are honest, the benefit there would be that if someone hacks into that provider, they won't get the password that you use for all your other accounts on the web.

My answer to that would be: if you use the same password for multiple service, you have no business getting all uppity about password encryption policy, because the security failure is you. If you care about security, use a different password for each service (a tool like 1Password makes that process easy). If you don't use a different password for each service, don't complain about security. I wish more people would realise the inherent hypocrisy of complaining that "you should encrypt my password because I use the same password on many sites". Fewer sites would have to encrypt passwords to appease those users.