The article doesn't use "User ID" in the sense of "username" (externally visible identifier, that likely is used for log in), but as in "mostly internal id thats used to reference a user across database tables, services, ...". If you use something that can change in there, you need to do the change across all those things consistently, which is a lot of potential for error.
I got that but I can't imagine why you would even use the User ID for anything if we're talking about the row ID from the database. If you're doing tests against a user's profile why not use their username? There must be some case-examples that I'm not thinking of...
I know that some services have a public-facing "username" and a behind the scenes unique identifier (which is a great UX model), I'm just focusing on the unique identifier. Which I would think should always be it's own column, whether it's also used for the public "username" or not.
> Because if you change that, all your relations between tables will break.
Okay, that is not a response to my question, which is why would you ever use the row ID for anything in your program. If you never use it, then it cannot ever be changed. Also SQL allows relationships based on more than one field, so it seems such a disaster could be easily avoided.
Or am I misunderstanding your perspective?