Elevation of privilege, a feature that was added in Windows SharePoint Services 3.0, enables you to programmatically perform actions in code by using an increased level of privilege. The SPSecurity.RunWithElevatedPrivileges method enables you to supply a delegate that runs a subset of code in the context of an account with higher privileges than the current user.
Although elevation of privilege provides a powerful technique for
managing security, it should be used with care. You should not expose
direct, uncontrolled mechanisms for people with low privileges to
circumvent the permissions granted to them.
Elevation of Privilege
If your code run under a farm admin(who is local admin as well) then you dont need this method, but issue is when user does not have the right permission then we need this. It runs using the App Pool account, so you must ensure that the App Pool account is a member of a site collection group with sufficient perms to to add/edit/delete or whatever your code is trying to do.
So their is always risk involve with it.Here are some points to follow while working with RunWithElevatedPrivileges.
Avoid using SPSecurity.RunWithElevatedPrivileges to access the
SharePoint object model. Instead, use SPUserToken to impersonate
SPSite with a specific account, as shown previously.
If you do use SPSecurity.RunWithElevatedPrivileges, dispose of all objects in the delegate. Do not pass SharePoint objects out of the RunWithElevatedPrivileges method.
Only use SPSecurity.RunWithElevatedPrivileges to make network calls under the application pool identity. Don’t use it for elevation of privilege of SharePoint objects.
http://www.enjoysharepoint.com/Articles/Details/runwithelevatedprivileges-in-sharepoint-2010-238.aspx
When and How to Use Run With Elevated Privileges (RWEP) in SharePoint
