I don't think hashes of email addresses are very secure. You can get all of the email addresses from the smtp logs. There are also massive email lists out there that the attacker could run the hashes against, like the adobe leak. Email addresses typically follow specific formats, such as firstname.lastname@gmail.com, and would be quite easy to bruteforce/dictionary attack. If the hashes were to ever leak, easily >95% would be cracked, especially if they are using single-round SHA512.
Sure, there's no silver bullet and the author never claimed it's perfectly secure (is there such a thing?). But this is definitely an improvement - it clearly limits exposure.
To successfully do a brute-force the attacker would also need the salt, which means that the database by itself will not yield any e-mail addresses.
Another benefit isn't a security one, but a user-friendliness one: This forces all emails to your users to be initiated by them in some way, which limits future business decisions about sending email by automated processes. Good for users, but may be bad for business.
I feel like particularly if you are storing user data in a way that is visible to others, you have a responsibility to be able to contact the author of the data, given potential abuse?
1) you can hash together email + randomsalt + password and then store randomsalt and the hashed value
2) you avoid passwords altogether by giving a user an authentication token to be saved as a bookmark perhaps? The token contains a cryptographic signature
For 1), How would password resets work? Wouldn't you need more than just their email?
For 2), This sounds like a bad idea for anyone sharing their screen, they could broadcast the url or even just share a link not understanding how it works and lose control of their own account. Also this would only work for users who use bookmarks.