You're missing the point. It doesn't matter if you have xp_CmdShell turned off and use .NET assemblies instead or not. The real problem is security. If you give users or apps "SA" privs (I strive to only give them PUBLIC privs and make them do most things through stored procedures), you're security is at risk whether you have xp_CmdShell turned off or not.

Using .NET assemblies instead of xp_CmdShell provides no elevated security whatsoever if the users or apps have "SA" privs.

Further, if a properly written stored procedure executes xp_CmdShell, you can give very low prived users the privs to execute that stored procedure (without them having the ability to execute xp_CmdShell directly) and it will be as safe as any .Net assembly you might write with the added benefit that the DBA can maintain it instead of having to manage separately written managed code.

Since only people/apps that have "SA" privs can use xp_CmdShell, turning xp_CmdShell off and not using it is a useless and futile measure because people/apps (attackers) that have "SA" privs can simply turn it back on or use another method around it. If people/apps don't have "SA" privs, it's also useless and futile to turn it off because they can't use it anyway.