Unfortunately, email is not a unique salt in the context of the internet. If the owner of the email uses the same password elsewhere (very likely), it's probably already in a rainbow table.
That is nonsense. You might want to check again what's a rainbow table and how it's used, because it's not what you think ^^
It's possible that another service use the same hashing method and email as salt and password. It's irrelevant at best when it comes to security. If the password was cracked it would make it's way to dictionaries, the password is compromised irrelevant of the salt and the hashing method.
The purpose of (properly) salting is to prevent against rainbow table attacks when your users table with password hashes is leaked, right?
That's why OWASP advises that salts be at least 16 characters long. This requires an attacker to generate a (currently) unfeasible number of rainbow tables.
However, if every web developer out there followed your advice, then the number of rainbow tables ever needed is reduced to the number of emails; assuming everyone uses the same hashing function. Sure there are a lot of email addresses, but maybe the attacker only wants to target users at @bigco.com. So now only 100 rainbow tables are required to cover the C-levels and VPs there.
If you know systems are doing SHA(password), you could generate a database of precomputed passwords up to 10 characters. That's called a rainbow table. It can take a year to generate one and take a terabyte to store. The benefits of the table is to make lookup really fast.
You could still try to brute force up to 10 characters on the fly or try a dictionary of known passwords. Having a precomputed table is much faster though.
Systems have to use a salt per user like HASH(username + password) because user+password won't be found in the table. This effectively break usage of rainbow tables. The salt only needs to be unique per user account, an email is good enough.
It's nonsense when you say to generate a table per user. It could take a freaking year to generate a table! That's not feasible.
That being said. For something like Linux or Windows accounts, if it were using something like HASH(username + password), it could be worthwhile to make a table because the username is always "root", so that use case should use something else than the username as salt. ^^
And it takes a week for 9 characters and a few hours for 8. The point is that with a random salt the amount of work that needs to be done is proportional to the number of accounts you want to break across all services, not just one. It isn't a ton of additional security (especially if an email account is compromised...why is everything so terrible), but it is strictly better and doesn't have failure modes like the same username being used in a billion devices.
The email is the salt. It's different for every hash which is all that's needed from a salt.