I few years back I took over development of an old PHP website, which had a horrible code base (no framework or library, not even MVC). This site had around 30,000 users, all with plain text passwords.
It took me all of a couple of hours to get the site using bcrypt.
I'm not saying I'm some kind of super-rock-ninja-star developer, just that this is so easy to fix, even on monstrosity, legacy code bases.
There really is no excuse.
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.
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.
It can be difficult to argue for security in cases where even small % of short term revenue might be affected.
The barrier is not difficulty. The barriers are lack of time to spend on infrastructure/security improvements, lack of motivation, and distraction due to new feature requests.
Of course forgoing these things will bite you in the end, but this is the internet age; people don't tend to plan that far in advance.
There are loads of sites built year ago that just work so nobody is looking into the code base ever.