The most noticeable change for Dynamics CRM with server-side sync as opposed to the email router is the user interface, where a person can do all the configuring without having to log into the server itself. While this is a great addition and makes things much more manageable, there are some downsides to it, which could potentially be a large factor when determining whether to choose between server-side sync and the email router.
The great thing, as mentioned, is you can add, remove, test, and do everything without requiring server access, since it can be done directly in CRM. For example, in the email router for incoming email, you have to edit an xml file to specify the threshold date, which will specify what date to start picking up emails from. So you don’t download the entire mailbox into CRM. With server-side, you can specify that value in the Configuration profile.
The bad side is that email settings can be potentially set and changed from a non-server admin. Think of a scenario where a CRM production organization is duplicated for testing purposes, but you don’t want to enable email, since data in the test environment contains client information and email addresses, and there likely are automated emails being sent from workflows. The control of whether emails can be sent from an org are no longer limited to a server admin, so you may end up with someone enabling server side sync in an org they should not, and as a result, clients will be getting old or duplicate emails, from both production and the test environment. Therefore, further checks would need to be in place when using server-side sync, such as disabling relay or Exchange access from the test environment.