Hi, maybe we are talking at slightly cross purposes re the risk between display and update. I can't figure out the quote system particularly well but here goes
when people ask for "spro display" and cannot take the time to articulate which areas of spro they need (in production), then it's the same as asking for s_tabu_dis / dicbercls = * and tcode = * and no security professional likes that.
I don't agree with your comparison. SPRO contains a set of relatively static (in that I mean they aren't hugely different between systems that aren't different IS-releases or similar) config options which, with some effort, can be mapped to transactions, table auth groups etc. Most of us have a reasonable role somewhere in our toolkit that can be deployed. It's common functionality and a common request that can, in most cases, be granted to the right people to display access with.
when using spro_admin to vacuum tcodes into roles, it ends up giving overacess and can fill roles with SoD, assuming those weird variant tcodes used in spro are even defined in a ruleset.
I refer to my previous post about having a suitable access prepared that deals with most of these "deviations". In the same way we sanitise any default proposals that SAP makes blindly using SPRO_ADMIN will of course provide challenges.
I have found that config teams needing display access to anything in production are able to articulate what exactly they need when pressed, and as long as there is a process to temporary elevate privileges in true emergencies, then teams fall in line and we can keep the production data protected, and prevent IT staff from having super access in production.
In what case would display access to config be an emergency rather than business as usual for many organisations? It is display, it's not superuser access by most definitions. For those responsible for dealing with it on a daily basis it is BAU access. To have to invoke an emergency process to display some config seems an awful waste of time to control something that, in most situations, doesn't require an additional level of control over it.
It is similar to enthusiastic controls designers who insist on OB52 being stuck in a FF process.
Cheers