It depends what you mean by "leak". If someone was running keyloggers and collecting passwords and they published them, that can also be a leak, and it doesn't matter how the passwords were stored. And not just keykoggers, but this also applies to phsihing, man-in-the-middle attacks, or other similar ways of getting passwords from end-users.

You can brute force a hashed password if it's short or you want it badly enough.

'Standard practice'.

And yet there are plenty of shops that will either symmetrically encrypt passwords (at best, the email address or username is used as an IV), Log passwords stupidly [0], have a piss-poor integration where "Oh we have base64 encode the actual XML payload in the soap service and tag it '<Encrypted>`, ship it!" [1], or are just plain too budget strapped to replace the 'forgot password' functionality that told a user their password vs forcing a reset.

And I think that last point hits it well. i.e. at least a plurality of those horrors were done before standard practices evolved to the current state, but nobody can get the budget/time to fix it. (And, I will say, having 'fixed' more than one of the above cases, it definitely has a user impact which can lead to the folks approving the work having an uncomfortable conversation with customers. B: "We forced a password reset to update security standards" C: "Wait so your security standards were subpar!!!" [2]

[0] - Example; logging invalid attempts, but wait a user only failed because they did TypoEmailAddress@gmailcom instead of TypoEmailAddress@gmail.com.

[1] - Yes. This was a thing I got to deal with once. What's even more annoying is that it was a SOAP service so of course the pattern eliminated most of the potential usefulness of a SOAP service.

[2] - That said, usually the person making this complaint, is the person who historically was e-mailing their account rep to give them their password, vs using the 'correct flow but bad implementation' password reset we had in place as a stopgap.