Any capability to a CNode is sufficient to perform any CNode operations on the caps stored in slots in the CNode including deletions. Being able to prevent another entity from deleting or modifying caps in a CNode is something that would be useful for implementing hardened functions within an app that can be relied on to not have been modified by behavior elsewhere in the app.
Program code that performs seL4 invocations can already be made immutable with read-only executable memory and data, but this can be subverted if the caps that the code is trying to invoke have been modified. By being able to restrict modifying specific slots in a CNode, an OS is able to provide functionality similar to a vDSO that can be installed in each app and would allow for an app to jump execution to an address that it can trust to correctly execute. This would be useful for functionality such as self-checking operations.
I think the above functionality can currently be implemented by using a fault-handling thread that is more strongly isolated from the rest of the app but this has a larger runtime cost than a local function call and restricts what else the fault-handler thread can be used for.
Also, this mechanism would allow static components to be slightly more robust if they can’t accidentally delete all the caps in CNodes they have access to.