Anyone with RUN_SCRIPTS can go to /script and immediately grant themselves other permissions (or disable security altogether, or worse), so it is strictly more powerful than anything else, including ADMINISTER. Yet the impliedBy link normally grants RUN_SCRIPTS automatically to anyone with ADMINISTER, which is backward.

Less obviously, with UPLOAD_PLUGINS you could do much the same, if you spent a moment writing a custom plugin with a malicious initializer and building an hpi file, then installing it dynamically. This leaves a bit more of an audit trail, but only barely. (Maybe SecurityListener should be notified whenever a script is run or a custom plugin uploaded, and by whom?)

If (as is common) all these permissions are granted together to administrators and not at all to other users, there is no problem, but the illogical impliedBy relationship together with the relatively innocuous-sounding permission descriptions combine to make even many experienced Jenkins administrators unaware of the risks.
t
At a minimum, the descriptions of these three permissions must clearly state what they allow users to do and the implications.

Next, ADMINISTER should no longer be taken to imply RUN_SCRIPTS or UPLOAD_PLUGINS, since such implications give the misleading impression that these are weaker permissions. They should need to be explicitly granted.

(There is an unfortunate settings compatibility issue, that authorization strategy configurations which previously granted ADMINISTER explicitly to a user with the expectation that RUN_SCRIPTS would be granted implicitly would after such an update no longer grant RUN_SCRIPTS, since existing strategies typically serialize only granted permissions and make no mention of denied permissions. If popular strategies were fixed to distinguish implicitly from explicitly granted permissions, perhaps they could perform a one-time settings upgrade in which RUN_SCRIPTS were assumed granted to users previously having ADMINISTER.)

Possibly RUN_SCRIPTS and UPLOAD_PLUGINS should even be made to imply ADMINISTER, as in effect they do.

Note that it is possible to configure a customized system whereby some users get ADMINISTER but not either of the two other permissions mentioned here, as for example *.ci.cloudbees.com does. One of the changes needed is for the authorization strategy to ignore impliedBy for these cases. With CONFIGURE_UPDATECENTER you could perhaps trick someone with ADMINISTER into installing a "trojan horse" the next time they updated something, though you might be stymied by the signature check. There are other permissions which could be used to compromise a stock system, such as Computer.CONFIGURE (with CommandLauncher), or simply having nonzero executors on the master, so such a lockdown has to extend beyond the ACL unless various other operations in Jenkins are made to perform stricter checks.