Just a hunch, but I've seen it many times at past employers.
It's a no-no when the provider has a duty to the user, such as when the user is a paying customer. It's probably OK when the provider is the employer and the user is merely an employee? I say this because employers regularly do much worse stuff, like running MitM proxies that log bank passwords...
In some cases it may be necessary to see the application from another user's perspective. In this case you build a function analogous to "sudo -i -u user" which lets the privileged employee use his own account to get a session under another user's account, while generating an audit trail.
However this is usually not the right answer. Google Apps does not provide an "impersonate" function, but API endpoints which let you dump all mail to your own archiving system (where your company can search it for investigations, legal discovery, etc.) This is more efficient anyway, and doesn't require the disclosure of user passwords.
You can also do this crudely by resetting the password in the database, gathering whatever you need to, and then changing the password back by replacing the old hash directly in the database. Then at least the impersonation is evident in your MySQL logs.
If there is an Excel sheet of passwords shared among managers, and someone does something nasty from an account whose password is on that sheet, good luck figuring out whether the perpetrator is the account owner, one of the n managers with access to the passwords list, or someone else entirely.