The issue of whether to use it or not also seems to go a bit beyond security, spilling into application design. If we break this down into two areas where xp_cmdshell might be useful:

1. For DBAs it is a convenient tool to get things done on the host OS'es operating system but could offer permission elevation and does allow for identity obfuscation. Alternatives: have the DBA run PowerShell or VBScript from their own workstation under their own account. For automated processes use SQL Agent or another scheduler where there is an option to run jobs under a distinct security context.

2. For Developers, using xp_cmdshell to expose functionality through stored procedures is analog to multi-purposing your SQL Server as a Windows Application Server. You still have the problem of identity obfuscation and the lack of options in terms of segmenting tasks so that least-privilege is honored. Alternatives: use an application development language separate from T-SQL to interact with file systems or resources external to the database engine, e.g. SSIS, .NET or PowerShell.

Trust is key but bottom line is xp_cmdshell is a security threat, by definition and in practice. The fewer exposures there are, the better off the environment is.