Suppose that instead of a typical User table, you have a User_Revision table like suggested. Every time a user updates their account settings, you INSERT a new row there. If a user changes their email address, you get a row each time they update it.
Not only the company gets an history of email addresses, but also they are tied to each other. If this information gets leaked, the user is exposed to more vectors of attack.
(This is what Tildes use: https://tildes.net/settings/account_recovery , and I found it very genius)
It does not work if you actually want to send emails, for instance notifications.
I like Apple's approach to generating random throwaway emails.
I also like apple’s method, but it is not either-or.
Perhaps someone should deliberately leek a bogus database that contains the bcrypt hash of davey.jones.490@well-known-email-provider.com and see if that account starts receiving spam ... probably it won't.
There is (almost certainly) no associated e-mail account, but the following is the SHA-256 hash of firstname.lastname.threedigits, something like "davey.jones.490". I'm half-expecting someone to reply with the solution, though I think there are about 36 bits of entropy in my choice:
b8b6395265714064afb525f37e9969a7dbf09a4a2afa28812e917580be2dc667