Powershell is very insecure and is heavily abused by potential attackers as it's more flexible than CMD.exe. Of course, arguing about CMD.exe vs PS.exe is pointless, but it still needs to be argued.
There has been a recent spate of talks in Blackhat conf. and other confs, about the versatility of PS.exe, how it is used to perform persistence in comparably little characters, or lines of script than CMD.exe
Some of my Win10 deployments even contain a script which silently disables PS.exe in the installation, and removes every reference to that executable in the registry. There are a few cases where I caught PS.exe re-spawning itself when a Win10 update arrives, so a PS-free deployment is hard to enforce.
I'm really confused here. What attack vectors apply to PowerShell, but not to a situation where I can invoke cmd.exe? I can tell PowerShell to only run signed scripts, and specify what signatures to honor, which is more than I can do with either cmd.exe or WSH. You're citing compactness of scripts, but a straight-up binary would be more compact still. I think I'm missing something pretty basic here.
Which is a post exploitation tool. Assuming you have a payload in Windows ready to execute, one typically wants to leverage tools already in Windows itself, like Powershell, which can make rootkits and other payloads have a lot less footprint, and make them difficult to spot using heuristics. Most crap payloads are actually easy to spot because their payload is massive.
Essentially my point is that you don't want to make it easy for attackers. For context, one would not want Powershell installed on 1000 Windows 10 installations.
I happen to get paid good money for deploying Win10 kiosks in different offices in my area and Powershell is one of many tools I routinely remove from Windows to decrease the attack surface in Win
Anything VBS can do, Powershell can do ("everything" that a running user has the security for). Number of characters isn't relevant to scenarios where you're running PS/VBS/CMD on a local machine.
PS - Your "PS breaker" machine configuration is going to cause problems. Several of Microsoft's installers already run PS scripts behind the scenes. Plus you're doing it for absolutely no technical reason (just ignorant fear).
There has been a recent spate of talks in Blackhat conf. and other confs, about the versatility of PS.exe, how it is used to perform persistence in comparably little characters, or lines of script than CMD.exe
Some of my Win10 deployments even contain a script which silently disables PS.exe in the installation, and removes every reference to that executable in the registry. There are a few cases where I caught PS.exe re-spawning itself when a Win10 update arrives, so a PS-free deployment is hard to enforce.