First, done properly, there is no additional risk. The only time such a risk occurs is if an application or non-DBA users are allowed to have "SA" privs. If such a thing happens, then you have [font="Arial Black"]much [/font]more to worry about than the use of xp_CmdShell. Even if you were to rename or even delete the DLL for xp_CmdShell, there are still super easy hacks to get to the command line if you have "SA" privs. In fact, following the rules to correctly instantiate the use of xp_CmdShell (and it's not obvious in Books Online) will make you tighten your security to what it actually needs to be.

Examples of why I'd want to use xp_CmdShell are two fold.

The first is cost. It's not likely that I'd ever allow the SSIS server (for example) to live on the same server as my production databases. They'd have to live on separate servers. If I can do everything from T-SQL using the occasional DOS command to move files, an ETL system would cost a lot less on an existing server instead of having to fire up a special server just for SSIS.

The second is security. It's a lot easier to keep one system secure than it is two. To use your own words, it cuts the "additional risk" in half simply because there's one server instead of two.

I won't get into intangibles such as not having to hire programmers that know a certain language to deal with all the scripts that developers tend to write in SSIS because they may not know how to do something in SSIS (or that SSIS simply can't do it) or the fact that those scripts are frequently written in T-SQL anyway.