I quite like the current construct where you have to show intention to add S_RFCACL to SAP_ALL and it does not "just happen" like magic. The reasons I am aware of are:
- The object is not a control of authorization. It controls authentication. So it belongs to the login family of security controls and not "all authorizations for the system".
- It is high up on the list of misuse candidates, and there is not effective way to prevent a person from discovering which users have SAP_ALL as a myriad of search helps in SAP provide the option to F4 users by Profile name. Searching for users by objects and authorization values is in contrast protected by SUIM access or table access. This is particularly true for non-Dialog users which can then easily be entered into external RFC connections without requiring knowledge of the target system password anymore.
- In the semi-likely event of the SAP system loosing cabin pressure due to S_RFCACL access granted to passengers, an oxygen mask will drop from the ceiling above the pilot's seat only... :-). SAP themselves have not included this object by default into any roles outside of the Z and Y namespace, it is not included into SAP_ALL automatically, in higher releases you cannot via SU24 nor the "distribute full value to open fields" button in PFCG provide any * access to some of the fields. You definitely granted this access yourself and it is optional to have used trusted RFC anyway.
So in conclusion your idea is a way to make your life even easier for SAP_ALL users, but I don't see that ever being implemented or changed now. On the contrary, the recent changes in the area show that SAP is becoming more restrictive and selective about defaults for security relevant features in the system which are optional to activate. That is a much safer approach than turning everything on by default and expecting diligence and audits to bend it back again - we know how that works from the past and don't want to go back there.
Cheers,
Julius