Steve you are not new to SAP security and know that all software companies prior to SOX, JSOX, etc, were not very restrictive on any system or batch account. Although most including SAP documented required authorizations in Security Guides, these documents were stagnant and incomplete. Each time functionality was added, the guide was out of date and the user was broken. When this occurs many security architects do not understand how to perform root cause analysis and assign SAP_ALL to get around the missing authorizations. Even SAP support would recommend this by mistake as a requirement.
With 1000's of these implementations implemented over a decade ago there had to be a better way to remove excessive access to S_RFC, S_TCODE, S_DEVELOP, etc. In recent years SAP has made major steps to clean up the sins of the past. ASUG, DSAG and others have pushed SAP to deliver software that does reduce risk from excessive RFC access, cross site scripting for web applications and even exploitation of an SAP system from the predefined RFC connections.
You have a risk of RFC hopping with RFC Destinations, log setting changes, escalation of privileges, impersonation, or even hopping through an entire landscape. There are tools today which help you to identify function modules that are being used. These can be assigned by name instead of by group greatly reducing risk.
SAP even has disclaimers like this now "We strongly recommend that you conservatively assign profiles SAP_ALL and SAP_NEW to users in your production system! If you are not careful, these profiles can weaken the overall security concept in your production system." Companies like Virtual Forge and Onapsis also provide services around the risks associated with S_RFC within your environment.
For some explanation on the S_RFCACL risk and where it no longer has unlimited authorizations automatically, check out the note 1416085 - PFCG: Authorization maintenance for object S_RFCACL.