If lots of sites all use user ids as a salt and all count up from 1 then a much weaker version of this attack applies: you can identify all the people who have both the same password and the same user id.

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.

"I can't see why a user id could not be used as a salt though" thats exactly how people break crypto implementations, it seems ok but you dont really know. Don't just invent your own way, use the standard one.