Interesting post, if we look at what is currently out there PowerShell is used by public exploits to facilitate tasks during exploitation, most examples are client side attacks against IE or leveraged by malicious Java Applets. We have also started to see it being used inside malicious macros and used in ramsomware so the the threat is real. From a sysadmin perspective solutions should be able to be applied uniformly across a entire network that as real world will be a mixed of different versions of PowerShell and Windows so a solution from MS must allow for this. As Matt mentioned auditing is important, as part of our regular monitoring of the systems for performance, availability and security like we do for most of our environment so better logging to the event log that we can control is important in my opinion. Better control on what cmdlets are allowed to run and under what privilege, same goes for controlling access to .Net. Some of these basic measure will provide control and reduce the chance of entry using existing tools used to manage and monitor a Windows environment.
From the point of view if they are inside they can do what they want when referring attacker I have seen pentesters, malware and hackers suffer because there are local controls in place. It means they have to spend time bypassing them and many times this will increase their forensic footprint and make an attack more prone to be detected. It will also break automated tools that expect a default configuration and block novice attacker whose skill set is still not developed. There is a Murphy law of combat that says “Professionals are predictable but the world is full of amateurs” The same applies to attackers in the cyber realm.
This are just my 0.02 since coffee has not kicked in this morning.