The goal is to ensure that ros2cli tooling remains function when security is enabled; at least to the degree capable in accordance with the permission granted. As for what permissions that are provisioned, and who is given those security artifacts is between you and your friendly sysadmin 
. I’ll paint a scenario to illustrate the use case.
Say some end developer, Bob 
, orders a black box robot 
by some OEM, ACME 
. ACME is in possession of both the Permissions and Identity Certificate Authorities (CAs), and continuously controls what artifacts are installed/deployed onto the black box robot. ACME, like any CA provider, also has a online portal where Bob can send certificates request and permissions for signing. This allows Bob to meditate who is authorized to communicate with the robot, while ACME can additionally regulate what permissions are granted.
Assuming the CAs are wise enough to only sign certificate requests with unique subject names, and access to security artifacts on the robot are controlled (via TPMs, ARM Trust Zone, Intel SGX, etc.), this would allow ACME to protect system critical interfaces in the robot, while simultaneously provisioning Bob with the minimal subset of permission necessary for developing with the product. E.g. enabling Bob to ros topic echo sensor data 
for calibration with the end user app, but not screw with factory set PID gains params in the safety controller 
.
Later, if Bob needs to take the robot to the local certified shop 
for repair, ACME could provision the shop with the admin level permissions to debug dagious or system critical interfaces. ACME would also take care to only issue such admin level permissions with a validity set expire after the expected duration for repair.
Ideally, I’d like afford Bob to be in possession of the Identity CA, since Bob is going to be held responsible for the robot in the end application, but this would require some alterations to the binding between permissions and identity certs in the default Secure DDS plugins. Presently this is via matching subject names fields, but could be customized to bind to something else like a cert’s public key. In any case, this paradigm will probably work against the Right to Repair, a movement I concur with; yet this is a service model I’ve seen quite a few robotics OEMs request for, and expect to see more of in the future.
I’m not sure I caught that either, but I’m guessing @dirk-thomas is asking whats the points of granting ros2cli permissions and credentials, if any old application could use those same security artifacts, e.g the transport layer security artifacts are not inherently bound to a specific application layer.
To that I’d argue that even though nothing inherently restricts one set of security artifacts from be used for a different purpose, aside from controlling access to those security artifacts, the benefit of selectly specifying the security artifacts for ros2cli tooling to use vs the rest of my ros2 application helps development. In the scenario above, I might want to have my ros2cli on my workstation to have super admin permissions (* for subscribe and publish permissions) so I can triage whether its the topic publisher or the subscriber in the robot that has insufficient privileges.