It could be viewed that way, and that would likely be the most fundamental and basic way to look at things in terms of where to begin securing a system. I am not taking it to that extreme, but it could be taken there, and I am sure it has. Consider any computer that has the ability to control the launching of a nuclear weapon. I would say that "power on" is one of those system functions where security needs to be considered.

One comment of yours in particular stood out to me. You're implying that if something is available, that by understanding how that thing works it makes it less dangerous. I would disagree with that assertion since it is not always the case, and I would say is not the case here. I understand how xp_cmdshell works but if it's made available in my environment that won't necessarily stop a developer from abusing it in an application design capacity, and it won't necessarily stop a DBA from using it to elevate their own permissions so they can gain access to files they would not normally be able to access. Because I understand it is why I do not want to make it available. Not everyone can be properly educated or trusted to use every tool properly or responsibly. That's just a fact of life.

Maybe hacking it out of SQL Server is a bit extreme. To be fair I am certain that many people have gained lots of utility from using xp_cmdshell, and probably built some pretty cool solutions. I am saying that at minimum I would like to see there be an option to raise the bar in terms of bringing xp_cmdshell online, i.e. make it an explicit installation option in addition to having to run sp_configure to enable it. I would say the same for things like OLE Automation (sp_OA procs), SQLCLR, and a few other SQL Server features as well.