An editor should be able to improve an article without having to work out which design choices might break the rest of the site. That is easier when the editing controls reflect the job they are trying to do.
I decide which parts must stay shared and which parts an editor needs to change for an individual article. Then I use the smallest restriction that protects that decision, explain it in the interface and check that it survives saving and reloading.
Decide what should stay shared
A synced pattern lets one change update the places that use it. Detaching an instance turns it into separately editable blocks. Both behaviours are useful, but they serve different purposes.
A shared contact panel might need one maintained version. An article introduction built from a suggested layout may need to become its own content straight away. I would not give both the same restrictions just because both started as patterns.
Before changing the controls, I ask who owns the original, what an editor needs to change locally and how a correction should reach every instance. That usually gives a clearer answer than deciding that editors need either every option or no options.
Keep the useful controls visible
WordPress already provides ways to shape the editor. Block locking and content-only editing can protect a structure while leaving appropriate content available to edit. I check those native tools before adding a custom control.
For any extra restriction, I want a short explanation beside it. If a pattern must stay shared, the interface should tell the editor where to request or make the shared change. Removing a menu item without explaining the route leaves them stuck.
Start with a few concrete editorial tasks and test the controls around them. A broader dashboard is worth considering only when it solves recurring problems that those smaller changes leave behind.
Test the saved decision
A toggle changing on screen is only the first check. I save, reload and open another use of the pattern. I check that a protected pattern and a flexible one behave differently, and that an update to the original reaches the intended instances.
I also test as an editor rather than relying only on my administrator account. Hiding an editing control is a usability guardrail; actual permissions still need to be enforced where changes are saved.
Good editorial tooling leaves people with enough control to do their work and a clear route when they need something beyond it. The fewer unexplained exceptions they have to remember, the more useful the system becomes.