Let me state at the outset that I like PowerShell, Microsoft's command-line scripting tool for its various servers. I don't "love" it because I'm not a PowerShell guru -- I'm an Exchange guy. I love when email goes from point A to point B. When I can create a mobile device policy and enforce it all in one line of code? I like that -- it's cool and saves me time. PowerShell is on my list of awesome tools.
But I also believe there has to be a reason why I'm using PowerShell: to automate tasks that would normally take me longer through a GUI. Microsoft has been increasingly requiring the use of PowerShell in its server admin tools. I've found in some cases a disconnect between the GUI and what you can do with PowerShell, removing admins' ability to choose the interface that's easiest for them.
Let me give you two examples from Exchange.
First, in Exchange 2010 on a Hub Transport server, I can enable antispam agents using a PowerShell script (Install-AntispamAgents.ps1). After running the script, the Antispam tab appears in the Exchange Management Console, so you can manage those agents through the GUI. But in Exchange 2013, running that same script on your Mailbox server doesn't cause any antispam controls to appear in the GUI-based Exchange Management Console; you can manage the agents. Instead, you have to use both the Exchange Management Shell and PowerShell.
Second, in the ActiveSync policies in Exchange 2010, you can adjust settings with simple checkboxes and easily determine, for example, if a policy would allow a user from using the smartphone's camera or open a browser on the smartphone. But in Exchange 2013, all the advanced settings have been pushed off to the shell, even though the policies still exist and some of their settings remain in the GUI.