They are deployed before temporary account deployment so existing abuse filters can be switched smoothly (user_unnamed_ip is available for anonymous users' IP address when temporary accounts are not enabled).

This is one of the few things that cannot be undone, so my question remains: why is this present in all filters?
It will be confusing for people to see two ways to hide a filter, one of which is permanent.

I can also imagine some bad actors activating the permanent protection before being desysopped and disappearing.

Couldn't this be done by limiting access to the log entries and filter revisions that were generated while user_unnamed_ip was in the filter?

cf: T378551 and T378553

Apologies for the confusion and thanks for filing this. I agree, the checkbox shouldn't be present for all filters and it has led to some confusion.

What happens if someone accidentally, out of curiosity, checks the confirmation box and saves the filter, will it stay protected forever?
What if a filter was created with user_unnamed_ip, but has never triggered (no logs) – the protection should still be reversible IMO

The filter would stay protected, and this has indeed been done by accident, e.g. T377765#10307225.

We're making a maintenance script to undo protection, in T378551: Create a way to unprotect an abuse filter. We're not allowing it to be undone by users on the wiki, to avoid mistakes where a filter that should be protected becomes unprotected. I've argued on that task that although there may be situations where it would be safe to unprotect a filter, it's not worth the cost of doing this.

We're fixing the workflow for protecting filters, so filters can't be protected by accident: T377765: Do not allow protecting abuse filters if PII variables are not used.

And as a quicker fix we've removed the checkbox from wikis without temporary accounts, by removing the permission to use protected variables from local sysops: T379503: Disable AbuseFilter protected variables features on wikis where Temporary accounts are not about to be released. (Users in some global groups still have the right, but the checkbox will be removed for them once the above tasks are done.)

In T378523#10317465, @Tchanders wrote:

We're making a maintenance script to undo protection, in T378551: Create a way to unprotect an abuse filter. We're not allowing it to be undone by users on the wiki, to avoid mistakes where a filter that should be protected becomes unprotected. I've argued on that task that although there may be situations where it would be safe to unprotect a filter, it's not worth the cost of doing this.

This has been done and will be run this week.

We're fixing the workflow for protecting filters, so filters can't be protected by accident: T377765: Do not allow protecting abuse filters if PII variables are not used.

This has been done, and will go out to our production sites this week.

And as a quicker fix we've removed the checkbox from wikis without temporary accounts, by removing the permission to use protected variables from local sysops: T379503: Disable AbuseFilter protected variables features on wikis where Temporary accounts are not about to be released. (Users in some global groups still have the right, but the checkbox will be removed for them once the above tasks are done.)

This was reverted, since sysops were already working on updating filters to use protected variables, ahead of temporary accounts deployment.

I'll close this task as a duplicate of T377765: Do not allow protecting abuse filters if PII variables are not used, since I think the concerns expressed here are the same.