While it is important not to reduce the benefit of a Dynamics CRM system by excluding activities that would be beneficial, often requests are made to include customization that add little business value but drive real technical complexity.
Consider a simple business scenario:
If every time we create a task we also update the user record with the number of tasks they currently have allocated, that could introduce a secondary level of blocking as the user record would also now be heavily contended. It would add another resource that each request may need to block and wait for, despite not necessarily being critical to the action. In that example, consider carefully whether storing the count of tasks against the user is important or if the count can be calculated on demand or stored elsewhere such as using hierarchy and rollup field capabilities in Dynamics CRM natively. Limited update philosophy should also be adopted while extending CRM using Processes, Plugins or Scripts.
This is something that reminds me of normalization in DBMS J
***References : Scalable Dynamics CRM Customization documentation