Consider this scenario: An organization is developing a custom site collection that will include various assets, such as file items within IIS virtual directories (for example, style sheets and navigation graphics), list items in SharePoint lists, and document templates in document libraries. When the development and test phases of the project are complete, the assets must be copied or moved to the production environment. If the range of assets is complex, it may be worthwhile to script the movement of these assets from one deployment to another. The PowerShell environment provides all the necessary facilities to make this possible.
Since SharePoint object model can be accessed from inside PowerShell scripts it is possible to build very sophisticated configuration and deployment processes by using PowerShell. When deploying SharePoint Products and Technologies, Windows Server 2008, and IIS 7.0, PowerShell brings several advantages:
Full access to the SharePoint object model: Before the availability of PowerShell, access to the SharePoint object model was only possible through the development of either console or Web applications, written in a .NET language, compiled, and then deployed together with any reference DLLs. In the PowerShell environment, all the namespaces within the SharePoint object model are available by inserting references to the required namespaces. Now Web administrators and developers can develop their own PowerShell scripts to access the object model. And PowerShell scripts are parsed for execution at run time so that no compilation is needed.
Cmdlets: Many cmdlets are currently available to access OS system services and objects. Also, the PowerShell environment is fully extensible; we can build our own cmdlets to perform custom processing and make these available to PowerShell scripts. For example, we can build cmdlets to query and configure SharePoint-enabled Web sites, with access to the both IIS 7.0 Windows Management Interface (WMI) and the SharePoint object model.
Another benefit of PowerShell when we combine it with the SharePoint object model is the ability to quickly build custom SharePoint utilities without having to develop and deploy compiled applications. Combining this technology with Windows Server 2008 and SharePoint Products and Technologies enables a whole new potential set of custom automated deployment and configuration processes by using scripts.
You can also find interesting to read: Getting All the Web Objects URL in a SharePoint farm using PowerShell Scripting