Hi Steve
Thanks for this discussion as I've had the same reaction too (hands up admitted that I updating PRGN_CUST to allow it to be added before learning the "you should never add it" mantra)
The other part that confuses me is if it is trusted then it's still your account. So even if I do have the access to jump systems I still need authorisations against my account to execute items in the target system (unless dodgy code is the risk here?)
The PFCG build part that gets me is the field requires to you to specify system id instead of a system alias. Therefore, if I transport my roles I have to allow add the dev, QA and production SIDs to my role and transport so I can use the role throughout the landscape (i.e. I need to test my production end user role in QA so I need the QA system to be in the role).
I take the approach of not granting SAP_ALL at all in end user clients. I build non production support roles and still push that system users get appropriate roles. It takes time to do and quite frustrating on a greenfield where you have to argue this. So in this case, if people aren't being granted SAP_ALL permanently what is the risk of the authorisation being in the role. Basis teams end up building a ZS_RFCACL role and assign it to themselves with the auth having astersisk.
Could part of the answer be just having this as an extra layer of security. By not adding it you have to be conscious in granting the permission so if someone does configure a trusted RFC connection it won't work. Also, if there are jobs running out of 000, 001, etc clients they won't get the trust value? Users in these clients typically do have SAP_ALL.
Regards
Colleen