Patient data, credit card numbers, personal data of all sorts, payment program, RFCs and file interfaces to systems which do have that data... I am sure you have something of interest in your SAP system or systems it is connected to via RFC... :-)
A downfall of S_RFCACL is that it has the system ID as a field. How do you build a role and unit test it in DEV, functionally test it in QAS and use it in PROD if your non-Dialog users have SAP_ALL in non-Prod systems but something restricted in PROD?
Given the information you have provided I would make a safe bet that that those users have SAP_ALL or a copy of it with S_RFCACL * in PROD as well.
I know of some administrators who even see the feature in this -> a user ABC tells them that Tcode XYX does not work. So they put user ABC into a trusted RFC connection in SOLMAN or any other under their control and just logon and start XYZ to take a look for themselves. An RFC call and also a batch job logon (also no password needed for the step user!) is not classed as a multiple login and knowledge of the initial or productive password is not required.
Your non-Dialog users are a bigger risk though than the dialog users. They can also logon. They also execute business functions. They often have SAP_ALL. They are just not capable of attaching the SAPGui to the session in the case of SYSTEM users, until they change themselves via RFC to SERVICE users. COMMUNICATION users are obsolete - do not use them anymore.
You should use SYSTEM users for RFC, jobs and also webservices. In a similar way to trusted RFC for DIAG and RFC clients, SYSTEM users cannot issue Logon Tickets in trust chains for http clients.
-> Not including S_RFCACL in SAP_ALL is intentional and should stay, as it protects people from themselves. This thread is a nice proof of that, so that should answer your own question... :-)
Cheers,
Julius