A lot of companies and services are storing unsalted hashes of passwords. Which is not much better than storing plain-text passwords.

It's becoming less and even languages with a "strong legacy body" like PHP have sane defaults nowadays, but I do see them around when I do consultancy or security reports.

"Never fix something that aint broken" also means that after several years or a decade or more, your "back then best security practices" are now rediculously outdated and insecure. That Drupal setup from 2011 at apiv1docs.example.com could very well have unsalted hashes now. The PoC KPI dashboard that long gone freelancer built in flask 8 years ago? probably unsalted hashes. And so on.

Given enough time, hashes are reversible via brute force.

If the attacker steals the entire password table undetected, they have a large amount of time to generate soft collisions. After all they don’t need to hack any particular account, just some 50% of the accounts.

The time can be increased by some coefficient via salting, but the principles remain the same.

For password hashing, only short-output or broken hash functions have practical collision concerns. The odds of any random collision with a 256-bit hash, and not with a specific hash, is 50% at 2^128 inputs. Salting is a defense against precomputation attacks like rainbow tables and masking password reuse. Attackers crack password dumps by trying known password combinations, previously compromised passwords, brute force up to a certain length, etc. and using the hashing algorithm to compare the output.

It's not about the email addresses themselves. Those are just the identifier by which things can be discovered on haveibeenpwnd. The point is that when email addresses rae stolen/leaked, they're usually accompanied by passwords, addresses, CC information etc.

In some cases the email address combined with the name of that site that leaked it can be enough to get people in trouble. E.g. "niche" dating sites.