The only scenario I can imagine where storing passwords in plain text is acceptable is when you are going for a CRAM-MD5 sort of authentication where the actual password will never go across the wire and even then it is a hell of a trade off and there are alternatives.
I'd forgotten that one. Hash based challenge-response authentication does require the server to know the plain password.
This sort of authentication is useful when you don't trust your transport mechanism (i.e. logging in over HTTP) but do trust the server's security. There are other ways to achieve this though. You could use DH or a similar key exchange method to decide a secret key (DH can do this without letting eavesdroppers know the key) to encode the password with for transport. You are then avoiding both plain transport and plain storage, where hashed storage on its own requires plain transport (unless the transport mechanism is separately encrypted, by SSL/TLS in the case of HTTPS) and hashed challenge/response requires plain storage.
Securing the transport (by using HTTPS with a signed-by-a-generally-trusted0body certificate, rather than HTTP or HTTPS with a self-signed cert) is the better option for a web based application though.
Of course, a site like PoF is not going to use any of the above. As has been identified (and, assuming statements in other comments here are true, admitted) convenience and laziness on the part of the programmer are far more important to them than DoingThingsRight(tm).
