Another very important category of PowerShell and PowerGUI users are software testers (a.k.a. quality control engineers). With these two technologies QC guys can start doing their work long before they get the final UI from the development team.
PowerShell nicely separates application logic from user interface. PowerGUI provides for a way to construct a UI from PowerShell cmdlets by just picking and choosing the ones to use. Thus, QC guys can start testing parts of a product long before developers make product UI good enough. Testers can just take the PowerShell cmdlets dev releases, create their own light UIs with PowerGUI, and use PowerShell scripts to automate testing.
In a nutshell (oversimplifying and taking design, etc. out of the picture) software development process consists of developers writing the code and at some stage (often called RTQC – release to quality control) being able to start giving some bits and pieces to testers so they can start breaking it apart. The current trend is to try to make the process iterative so developers are able to give the product to QC more often in smaller chunks rather than spend months (years) developing and then giving the whole huge piece to QC.
The problem is that quite often doing such small iterations early is not that feasible because of the user interface being the bottleneck and lagging behind the business logic implementation. Turns out that the problem gets significantly mitigated once development starts using PowerShell to implement the application business logic.
Once any cmdlets become available testers can start constructing UIs from them with just few clicks and keyword search. And even better they can start taking the PowerShell code and using it to create UI-independent code to automated testing.
Microsoft Exchange team claims this non-UI testing helped them in their last release process. And it looks like the interest to using PowerShell to make software testing more efficient is gaining traction.