That's part of the misperception. For example and just like xp_CmdShell, there's no natural auditability or logging (and I'm not talking the LDF file) if someone deletes rows from a table. And while the tools mentioned are good ones (.Net, SSIS, etc) and I encourage their use if that's your nature, they add a fair bit of complexity to what should be simple database or operating system tasks. Some of the tools, like SSIS, require not only more complexity in the form of learning another "language", but they also provide yet another attack vector and, unless programmed to do so, don't do any more logging than xp_CmdShell does.

Also, one of the key points of the argument to turn off xp_CmdShell that people seem to dwell on is that turning it on is logged. Like I said before, if that happens due to an attack, whether it be from the inside or the outside, it only provides written testimony that your basic security is woefully lacking.

If your system is secure, only the right people and things will be able to use xp_CmdShell. Let's concentrate on the real problem because if your system is not secure and whether you use xp_CmdShell or not, the wrong people will turn it on and use it or some workaround (and there are a great many such workarounds) to cause great damage or "just" steal your secrets on an ongoing basis without you ever knowing it. To wit, instead of being an effective layer of security, turning off xp_CmdShell and not allowing the DBAs to use it is like putting a very thin veil over rotting meat and the flys can easily get around or even through the veil.

xp_CmdShell isn't a hole in security. Bad security is the only hole in security.