I disagree, because that would be ignoring user input, especially in the case that the administrator changes the setting.
You are already ignoring user input, my example shows that explicitly. My proposed implementation removes that behavior and again puts the user (or admin) back in control of their own choices.
Use case example #1:
User chooses to login and for whatever reason (the reason is irrelevant it is simply the users choice at that point in time) they check Hide my online status this session, so they enter that session as a hidden user. Let's assume 10 minutes go by and User is now in their UCP board preferences and decide they wish to unhide themselves. They set Hide my online status: to No but they remain hidden. The application is taking it upon itself to ignore the latest user input in favor of older user input as if the application presumes that it knows what User wants more than User does. What rationale are you basing that behavior on? How can you assume that a User choice made 10 minutes earlier should be honored but the most recent input should be ignored? If they had the freedom to turn something on that they now wish to turn off, who is the application to say they cannot?
Use case example #2:
User chooses to login and for whatever reason (the reason is irrelevant it is simply the users choice at that point in time) they do not check Hide my online status this session, so they enter that session as a visible user. Let's assume 10 minutes go by and User is now in their UCP board preferences and decide they wish to hide themselves. They set Hide my online status: to Yes and voila! they are hidden. The application is now choosing to honor the latest User input(to hide) and ignore the older input (not to hide) so why suddenly does the application think the User can make such a choice? If User made a conscious choice to not hide their online status for that session, why should they get to change their mind when they cannot if the opposite were true?
There is no conflicting input, there is simply older input being overridden by newer input. The most recent user input is what should be honored, in any workflow. The existing behavior ignores current user input when it comes to 50% of the functionality of hiding your online status. My illustration of the correct behavior ignores no user input and makes the existing functionality work 100% of the time. If these last two examples (the use cases) do not illustrate the discrepancy in the existing behavior, I fear nothing will.
I have no idea what you mean when you keep saying "principle of least permissions" because in this scenario the state requiring the least level of permission is being visible. In order to hide you must have explicit permission set to do so, therefore a higher level of permission. Since no permission is required to be visible and it is the de facto state of all users, the ability to make oneself visible should always possible.
Changing a non-bot user's online status to hidden takes effect on the user's next page load, not immediately.
Immediately in that context was as in "not requiring a new session", a page load is required to update the existing session regardless of whether the user does it via the UCP or an admin does it via the ACP. When the user does it themselves the actual submission and subsequent page reload in the UCP takes care of updating it. When the admin does it via the ACP they have to wait until the user does something, might be a bit delayed if the user is sitting on one page but it does get updated when done via the ACP, without a new session.