It really depends on your size, and how sensitive the data is. At small size with non-sensitive data, where you've got 2 guys with admin access to the db anyway, simple impersonation is fine as they've already got access. You don't want to be spending a ton of time engineering a really complex solution. You probably should have a policy in place, and any staff you do give access to the feature explain the responsibility.
Most (small) startups I've worked at have usually had a homegrown solution with admin only access where you can login as the user.
However, these days, with more and more PII laws coming in, you do need to consider whether you really need it.
As you grow you have to add more checks, logging, etc., the user has to approve an access request, etc., to the point where you get bigger you don't allow it at all.
It's actually rare in my experience to need to impersonate a user to replicate bugs if you read their support request/ask the right questions, and can be a sign of an inexperienced dev if someone constantly asks for this. You have to put yourself in the mind of the user, what were they doing, what were they clicking, what were they trying to achieve. You'll usually be able to replicate it.
But another way to fix bugs due to complicated data interactions, when you're not allowed to access the data, is to have a script to anonymize the PII in a backup DB.
