Check-in policies, as we just saw (in Chapter 5, The Guide Standards for Check-in Policies), run completely on the client. This allows us to provide a nicer user experience, because validation is done on the client, whereas server plugins run completely on the server. Therefore, we can't launch any kind of UI on the server and rather have to rely on only sending helpful messages when validation fails.
You are able to override a check-in policy warning and proceed with a commit against any policies that are setup for the team project, whereas server plugins have no way to override unless you build logic into them that only validates on certain types of data making them ideal for when you need to enforce some behavior.
With check-in policies running on the client, the computing resources for whatever operations are required run on the client. On the other hand, with server plugins, all of the logic is executed as part of the overall request to TFS. So...
