First and foremost this article is a feedback from the field of a very particular case of SharePoint development. Telerik products and components are very good and accelerate your developments (SharePoint or not) providing you advanced and customizable controls.
Some of you already know it, I work in a team that develops products for SharePoint (www.oceanik.com and the others one do not have yet dedicated sites, we still have work on the marketing).
Developing products is quite different from the development of specific solutions (to address the need for a particular client in a particular context). Indeed your product will be deployed in a multitude of complex and different environments and be used for the same initial need but in varied ways.
In this context we used telerik components in our SharePoint products. After several months without problems some of our clients said that since the installation of our products some of our features did not operate correctly or even that other developments were all not working anymore.
The problem? They already had a version of telerik deployed, either via the telerik for SharePoint components (which embeds the telerik for asp.net components that we use) or because other products/custom developments. We had a conflict with versions of telerik.
The solution? Redirection of assemblies you would say. Yes but when using this kind of technique we must specify which request version is mapped to which version of the component. If it is something on which we can support the client, it is difficult to industrialize the process, as impossible to know in advance which version will have client. Another detail, the themes available have changed as much as versions, which also crashed our features.
The real solution? We had to get rid of telerik. In our case we were simply using grids, and we replaced them with javascripts controls (kendo ui, again some telerik stuff).
More generally, the development of ‘full-trust’ solutions unfortunately does not isolate the context of execution, this is also what led to the new apps model for SharePoint. My advice for all your SharePoint full trusts development: reduce to the minimum possible (cost constraints) your dependencies to third-party components.
In the same way always localize the use of javascript libraries (ex: jquery noconflict), you never know if one of your customers will not have an old version of the same library that will cause problems.
Obviously all these problems do not arise with apps, so here is my last tip: only make full trust solutions if you absolutely need to.