Currently people with certain Account Protection Profile levels cannot be impersonated based on your Security Settings. Generally speaking this is a good thing, it minimizes the potential that accounts with significant access will be compromised. But there are a few ways impersonation restrictions could be altered maintaining the safeguards while improving user experiences for admins and users.

1) When someone lacks the ability to be impersonated do not return the text 'tokenprohibited' as the token. This is helpful for debugging purposes but leads to a less than ideal user experience for individuals who are already logged in and did not need the token in the first place. The user experience is less than ideal because it asks the user to login again when they don't need to.
Note: If this is implemented, some page routes may need to be updated such as the photo request page so that the page can still be found without the token parameter in the URL. A simple workaround that can be implemented by Admins today is to use the replace function like so

{%- assign url = url | Replace:'TokenProhibited','' %}

2) Allow the PersonImpersonationToken and PersonTokenCreate lava filters to optionally generate a token for any user if a PageId restriction is provided. The use of a PageId restriction (depending on the page) can significantly reduce the risk associated with generating person impersonation tokens.

3) Allow Admins to impersonate any user from the person profile page. User impersonation is one of the key vehicles through which admins carry out testing for new features. One way this could be implemented is by temporarily changing a persons Elevated Security Level so that you can impersonate them. I currently have a workflow that will automatically reduce and restore the Elevated Security Level for a specific profile to its original value after a certain period of time. 

4) Provide separate actions on the Profile page for impersonating on the internal website vs external. Admins have the desire and responsibility for testing features that are access specific on both the internal and external website. Right now you have to change your block settings each time you want to toggle from one impersonation start page to the other. This feature could be especially helpful for admins who have recently migrated to Rock and are fine tuning their permissions. While it is not ideal, I did type up a recipe of how a second impersonation action could be implemented in Rock as is.