“Rogue actors” in the OP was the clue.
Hypothetical: one day, CuriousGeorge shows up at your studio and he has the permissions in Shotgun to create Tasks on Entities. For whatever reason, he doesn’t see a Task on an Entity that he thinks should exist, so without consulting anyone, he creates his own Task on that Entity. Also, because he hasn’t consulted with anyone, he makes his own assumptions about naming and Pipeline Step, etc. He doesn’t have permissions to create, edit or delete Task Templates, so whenever he comes across an instance of a said Entity while he works, he creates this Task on it manually through the web UI. Maybe he’s consistent in his approach (e.g. naming), maybe not.
While this is a social engineering problem at its core, a software engineering solution would be the restriction I described – no more worrying about rogue action. Users would have to discuss with production + pipeline if they wanted/required new Tasks, and then if there’s consensus, the new Task gets implemented properly and pushed out globally for the Project. If CuriousGeorge tries to manually create a new Task that doesn’t fit the Task Template, the restriction would prevent it from happening.
Where I work we’re planning to add new User Permissions groups, tweak their settings, and move the appropriate people/positions into them (currently based on legacy there are too many people in the Manager User Permissions group, for example), but as a short term solution I thought there might be a way to implement the restriction.
This isn’t a solution to the problem I’ve described.