The salt should always be random. If it's based on some account information it's possible that the salt can be regenerated if that account information would become available, in a DB dump like this for example.
I'm not sure how you can keep the salt random and secret, and still use it when users log in?
I can't see why a user id could not be used as a salt though.
If this were common, someone constructing a lookup table for password hashes could include ones salted with the first N user ids. A N-times bigger table isn't something you'd be excited about as a cracker, but might still be practical.
If your user ids are randomly assigned this should be pretty much the same as generating a random salt. Still, the extra storage of a salt is going to be small compared to whatever else you're storing per-user, so better to do the safe thing and go with what's standard.
If Adobe has taken that approach, the intruders would have all the salts, but they would not be able to do this attack of seeing how many people use the same password.
However, Snowden's silly password hint would still have given the game away. If that is in fact him.
Exactly because you need it to calculate the hash and compare it.
If you want to get more security on top of that out of your salt, the only thing I can think is to add some security by obscurity on top: If it doesn't matter which field in the DB you use, just pick an unlikely one and keep secret which one it is. Might be id, email, favourite pet, or something else. Just don't forget to update the hash when the user changes that field.