If a site is using plaintext password often the owner asked for it. They wanted their users to be able to recover their passwords. And the dev didn't understand why this was a bad idea. They need to be educated, convinced and then convinced that the time you're about to spend on fixing this is more important than the 101 other things going wrong because the original dev wasn't very good. And isn't actually causing a single problem right now.
That also means that the password recovery function uses this code. Maybe there's an auto-user generator when you sign up for the newsletter. The email system obviously also uses that code. That also sometimes even means the password is stored twice, once in the framework's user mgmt tables and once in a user or person or the tblPRSN_UPDATED_OPTIMIZED_mc table. And just deleting that column might cause all sorts of other problems. Setting it null might cause bugs. Setting it empty string might cause a massive security hole as there's a login mechanism you haven't even found yet. (remember the dropbox breach?)
It's never a 3 hour job to fix unless you're very bad at estimating, are working on something extremely trivial or do a half-ass job, potentially introducing a far worse security hole.
It's quite possible the dev knew it was a bad idea and maybe even argued against it but was told to implement it this way anyway.
The problem a dating site probably has is people who sign up accounts and then stop using them. They want to send these users reminder emails in the hope that some of them re-engage.
Problem is that some of these users have probably forgotten which password they use for that website, and some % of those will not bother using the password reset mechanism.
So someone in marketing has the bright idea of sending emails that include the username/password combo, the dev explains why this is a terrible idea and then gets overruled.
I include an "Instant Login" link in each mail so the users don't need to remember their password. It contains a unique time-sensitive token to identify the user and instantly sign them in (much like a password reset). I learned this technique from OKCupid, so no idea why they still had plaintext passwords.
Maybe simply emailing the password still has a higher conversion rate than the one time link, for example if the user does not see or understand the link or perhaps they want to login later when their email is not open.
It can be difficult to argue for security in cases where even small % of short term revenue might be affected.
If a site is using plaintext password often the owner asked for it. They wanted their users to be able to recover their passwords. And the dev didn't understand why this was a bad idea. They need to be educated, convinced and then convinced that the time you're about to spend on fixing this is more important than the 101 other things going wrong because the original dev wasn't very good. And isn't actually causing a single problem right now.
That also means that the password recovery function uses this code. Maybe there's an auto-user generator when you sign up for the newsletter. The email system obviously also uses that code. That also sometimes even means the password is stored twice, once in the framework's user mgmt tables and once in a user or person or the tblPRSN_UPDATED_OPTIMIZED_mc table. And just deleting that column might cause all sorts of other problems. Setting it null might cause bugs. Setting it empty string might cause a massive security hole as there's a login mechanism you haven't even found yet. (remember the dropbox breach?)
It's never a 3 hour job to fix unless you're very bad at estimating, are working on something extremely trivial or do a half-ass job, potentially introducing a far worse security hole.