That's the way it works today in some organizations:
If users can't delete their key they are requested to ask their GnuPG admin, they actually do so and the admin does help.

Experiences from customers are that people create their certificate, upload it to a server. Then they notice a mistake in their name and delete the whole cert and upload the new one. Now there are two certificates on the server. This is only one example of what can go wrong. Admins want this not to happen and that's the reason for this feature. More warnings will probably not solve the problem.

If you want to use gpgpass without a secret key, the most I would offer, if at all, is the option to use a symmetric key instead.
Maybe like this:

What's the use case for multiple designated revokers?

Alternatively the revokers could be listed in a separate tab in the details dialog.

There could be several designated revokers, and it's a direct key signature.
So it's like a certification, but not linked to a user ID, but to the key.
Therefor it can't be stored in one field.

Also required for an actium feature with UI.

Brainpool Cert on Disk is not relevant. Disable backup function for this case.

With Ingo's suggestions it could look like this.

Optimization requests:

The action shouldn't be enabled for keys not meeting the requirements.

This sounds good.
Will this checks be done on opening the context menu for a private key?

Of course, it should be possible to toggle "disabled" in Kleopatra.
A (context) menu entry "disable certificate" (or "enable certificate") should be sufficient.

When working on filters the "disabled" flag should be considered as well, see T7089.

I think we should separate this into two tasks:

For better action names see T6420: Kleopatra: improve layout of and text in smartcard management view.

I will re-test it with KDE neon.

A workaround you can add the following line to ~/.ssh/config or /etc/ssh/ssh_config: