Ensure compliance: TFS Plugins can ensure the enforcement of policies are not overridden. Checkin policies can be overridden by the user and only a notification of noncompliance is stored. (Think of TFS Plugins as
guard rails and check-in policies like
rumble strips.)

Ease of configuration: TFS Plugins can have their configuration maintained in a centralized location that spans all team projects. Checkin policies are configured for each team project which results in a higher maintenance cost.

Ease of deployment: TFS Plugins are easy to deploy as the bits live on the TFS Server. Checkin policies are difficult to distribute to all TFS clients.

Plugins

Branch Merge Check-In PolicyProvides allowable source and target branch location. For example, branches from a "main" branch can be configured to only be created in a "development" folder. In our example configuration, we follow the
code promotion branch model as shown below. This allows for branching between an "integration" and branches within a "development" folder. Then branches within "development" may be branched to a "CodeReview"
folder, which then allows branching to a "Staging" folder and likewise "Staging" to "Production".

Change Type PolicyPrevents users from checking in to certain areas if the changetypes associated with each item checked in are not configured. In our example configuration, if a change type is of type branch, merge, rollback, delete, or undelete in
the "Integration" branch or "CodeReview", "Staging", or "Production" folders, then it is blocked.

Inherit Only for new Branch SecurityThis simple policy removes explicit permissions to the newly created branch that would have otherwise been cloned from the source branch.

Forbidden Patterns PolicyPrevents users from checking in files with forbidden filename patterns. For example, stop your users from checking in compilation output (dlls), adding personal user settings to source control or even using programming languages that you don't support.
(This is basically what's found in the Power Tools version of the client-side check-in policy except that it also allows for friendly error messages.)

Work Item Association Policy
Ensures that the associated work items to a checkin comply with standards that you set. The following standards can be enforced:

Specify work item queries whose results will be the only legal work items for a check-in to be associated with. (e.g. Require an active task that is assigned to the submitter.)

Stop check-ins if the associated work items match the results from a work item query. (e.g. Deny direct assignment to work items categorized as requirements.)

Limit the work in progress so that each commit of code reflects one task. (e.g. Enforce that only a single task is used for each check-in.)

Ensure associated work is set to a current iteration. Iterations classified a past or future (determined by the iteration's start and end dates) will not be allowed.

Pattern Bypass Override
Allow for certain version control paths defined by Regex get a free pass on server-side check-in policies.