Why don't more websites that are vulnerable to these types of breaches also encrypt user email addresses as well any personally identifiable information? I don't foresee any performance implications if everything is cached anyways.
with e-mail addresses you need to use them in their unencrypted form (e.g. as login names), so encrypting wouldn't do much for you against most attacks.
For example to handle the case of unattended server reboot, you'd be likely to have the server have a script to load the key back into memory. Attacker gets shell access, they get the script, they get the key...
Security is always a trade-off and people tend not to engineer their webapps with the assumption that they'll be breached in specific ways.
tar czf - / | nc example.org 1234
... which requires the encryption keys to be know at the point of use - but it doesn't mean that they need to be kept with the database. It doesn't necessitate asymmetric encryption either.
If you keep the keys in a different location, completely away from the database server(s), then a compromised database or backup does not compromise any of the information. Of course there are attack routes that would still give access to the keys too, but you have covered quite a few common attack vectors.
The only way to protect against this would be some type of hardware key store with limited access to all employees and servers. I think there are a few (expensive) options which can do this, but nearly all services - especially startup services like this one - do not have this available to them.
Who knows if those hardware options aren't just as vulnerable to an experienced attacker though? I don't think they are generally well tested - probably half of the available options are snake oil.
To achieve that you would need human interaction to bring up a new box (or after an existing box is restarted) in order to hand over the keys (if the server could request the key from somewhere on the local network, then perhaps so can an attacker if they get access to run arbitrary things rather than just getting access to the filesystem or a copy thereof) which might be impractical for some environments, but it is possible.
For instance when my offsite backup server reboots it can't access the encrypted volumes until I login to mount them manually, sending the keys over SSH in such a way as they don't get stored.
The weak point then becomes the humans and the process they use to transmit the keys from the keystore to the servers.
In a big company though, having that one developer with full keys to the kingdom and is the only way to start up new servers is obviously out of the picture. Especially if the system works by having the keys on an easily stolen or damaged laptop...
Being able to dump RAM pretty much breaks the protection that this offers though, as you correctly point out.
If the whole machine is owned, then I guess it would possible to set limits on these operations. Or at least it can trigger an early warning.
This would also work when someone has forgotten their password, as long as they don't forget the email address they used to sign up. (This is actually the only reason why the user name has to be the same as the email address.)
You can't send regular information emails with this, though.