I agree, but this doesn't give much guidance about when global state is okay.
The way I think about it is that if you create a global variable for a user, you are saying that there is always a one-to-one correspondence between a user (maybe the current user) and a process.
In some apps (such as command-line apps) you can assume that the OS user is always the current user. But if you ever write an app that might be used by more than one person, you probably want to keep track of which user you're currently talking about. For example, are there multiple profiles? User switching? Simulated users in tests? There are relatively few objects that we can sure will always be one-to-one with a process. When writing libraries this is especially uncertain since you don't know the app's architecture.
The way I think about it is that if you create a global variable for a user, you are saying that there is always a one-to-one correspondence between a user (maybe the current user) and a process.
In some apps (such as command-line apps) you can assume that the OS user is always the current user. But if you ever write an app that might be used by more than one person, you probably want to keep track of which user you're currently talking about. For example, are there multiple profiles? User switching? Simulated users in tests? There are relatively few objects that we can sure will always be one-to-one with a process. When writing libraries this is especially uncertain since you don't know the app's architecture.