The difference is in the kind of audit trail it leaves. If a sysadmin impersonates a user, that leaves a different kind of trail than a user logging in with their own key that only they can access.
In principle, the sysadmin should explicitly avoid knowing any of the user's secrets, because if they do, the user can shift blame onto them: "It wasn't me, it was the admin!".
I will never generate a private key for a user and will initiate a reset process for any passwords and other personal secrets revealed to me; to do anything else would be irresponsible.
Unless it's all encrypted with the user's own password: sure, you can always invoke the admin powers and override the password field in the database or whatever. But the default mode should be that an account is only accessed by the person it belongs to.
Even as a security firm we have some exceptions in our company (disk encryption password for a physical device in the office is in a shared vault, for example), or support might do a remote control session with the user present, but it's definitely not the default setup procedure for a new employee to have shared credentials for example.
I think it should be noted that even with with encrypted data you'll generally just encrypt the master key with multiple passphrases; one (or more) master keys for admin use and one for the user themselves. There's really very rarely a good reason to share any secrets.
It's pretty much a necessity for any larger business that device data be protected with the user's own password and with a master password known to IT so that it can be accessed when the user's password is inevitably lost.
In principle, the sysadmin should explicitly avoid knowing any of the user's secrets, because if they do, the user can shift blame onto them: "It wasn't me, it was the admin!".
I will never generate a private key for a user and will initiate a reset process for any passwords and other personal secrets revealed to me; to do anything else would be irresponsible.