This is a short argument about a restriction that sounds petty until you trace what it prevents.
The loop
An administrator console exists to change other people’s access. If it can also change the administrator’s own account, then anyone who reaches that console once can adjust the conditions under which they keep reaching it: contact routes for recovery, exemptions, the attributes other checks depend on.
A compromise that can modify its own preconditions becomes self-sustaining. That is the whole concern, and it is why the restriction is worth the inconvenience.
Why a policy is not enough
Every organisation I have worked in had a rule like this written down somewhere. Written rules are followed until the night something is broken and the person fixing it has the console open and a deadline. The useful version is the one the interface does not offer, because then nobody has to remember it at the wrong moment.
The same reasoning sits behind two related rules: employee accounts cannot be impersonated, and a test user can never be categorised as an administrator. Both are constraints the platform enforces rather than habits it encourages.
The inconvenience is the point
Administrators still change their own details — through their account, in the ordinary way, subject to the ordinary checks. What they cannot do is use elevated tooling to alter the identity that elevated them. If that feels like friction, it is: a small amount, in exactly one place, aimed at the account that would do the most damage.