My opinion is that the best-kept secret in the CRM SDK is that you can use the SDK assemblies directly and completely avoid the problems of adding a web reference to your CRM directly into your development project.

First off, I will give a little background for some of the new CRM developers out there.  Most CRM programming examples start out by having you create a web reference to your CRM services (there are three services in total).  When you add a web reference, you have to give the web reference a name and a namespace.  What happens under the hood is that this information is used to build proxy client classes that can be used to consume the services in your client application. As a result, many of the code examples you see don't compile on their own until you add a web reference, and when you do that, you need to add it with the exact name and namespace that was used in the code for this to work properly. 

Another consequence of adding a web reference is that you now have a url to your CRM embedded directly into your code.  Nobody in their right mind will be developing against their production CRM, so in essence, you will really have a url to your development CRM instance in your code.  You have two choices at this time - you can change the code before you deploy (bad idea), or you can add an application variable to your configuration file and then substitute the url in code at runtime.  This means additional code, and each code example you find has a differnent name for the application variables, and there are more than one of them because you frequently also have to provide credentials as well.  Finally, none of this works for CRM Online, nor for SPLA deployments.  You will find that most CRM examples out there will only work for on-prem deployments, which is really not that ideal.

Another issue with using a web reference is that the web reference to your CRM is a dynamic web reference.  Microsoft has decided to model out your CRM entities and customizations in the web reference to give you some classes to work with.  For example, you will see a contact class with all the attributes in your contact entity.  At first, this looks pretty convenient, but consider that the service wsdl changes every time a business user customizes the CRM and hits the publish button.  What you are left with is a dynamic contract.  Contracts are supposed to be fixed in my opinion.  It is too fragile to have a dynamic service reference that can cause runtime errors in your existing applications just because someone customized the CRM by cleaning up an unused field or adding another one.

Microsoft has a better way for you to use the CRM.  They have included assemblies (microsoft.crm.sdk.dll and microsoft.crm.sdktypeproxy.dll) in the CRM SDK.  These DLLs have everything you need to fully utilize the CRM.  When you use these DLLs, there is no reason you have to add a web reference to your project.  They are so easy to use that I am surprised that not all examples are written to use them.  It certainly would make for a better getting-started scenario as all examples could compile and run without any code changes.

The most significant difference you will find is that you will have to use the dynamic entity when you work with your CRM entities.  I view that as a good thing (check out my other blog article).

When you are developing plugins, you are forced to use the assemblies in the SDK, so eventually you will find that you have to know how to use them anyways, so in my opinion, it is better to use them everywhere and get rid of all the problems of using a web reference.

When you start to work more with the CRM SDK, you will eventually use some form of connection or configuration library, and any reusable library will need to use the SDK dlls as well instead of your web references, especially if they are compiled into a seperate dll.