When you think of PowerShell, what comes to mind? Scripts? Probably. Of course, one of PowerShell's core focuses is about scripting; the other is a great shell.
Most developers think of "scripts" as lesser beings. Scripts are like the annoying little brother to software applications. Scripts are something that's just ad-hoc thrown together to automate some menial task that's been bugging you. Sure, there are lots of times when this use is still valid, but PowerShell has turned into something much more for some people in this DevOps world we're in today.
PowerShell has turned into not just a scripting language but an automation language. Features like the Azure Shell, Azure functions and building entire DevOps release pipelines are three great examples. PowerShell has become not just a scripting language like it's predecessors VBscript and batch files were. Because Microsoft has poured so many resources into PowerShell, and nearly every team at Microsoft now has PowerShell support for it's product, it's turned into the glue that fits everything together.
Other than using PowerShell directly in the cloud like Azure does, lots of forward-thinking shops are now using PowerShell as a key tool in their production processes. One core component in using PowerShell as an automation language involves using modules. Modules are the automation building blocks in PowerShell. Modules allow vendors and customers alike to create a "package" of functionality around a particular product, technology or purpose. Modules allow people to compartmentalize functionality and easily share it.
Read: Don't Assume Anything In Code (PowerShell Coding Best Practices)
People new to PowerShell may watch a course on building modules, create a simple module and get some benefit out of it. But what they don't realize is how extensible this module concept can be!
For example, I'm currently employed as an Automation Engineer. My role is to help automate test environment provisioning, application deployments from developers and so on. Imagine just what a test environment may look like. We're talking near-replicas of a production environment consisting of load balancers, web servers, database servers, file servers and so on. Each of these objects needs a specific configuration applied under specific circumstances, and the effort to automate all of this stuff is a behemoth of a task. PowerShell itself couldn't handle all of that, right? Wrong.
Running New-Infrastructure and bringing up 10 web servers, 2 clustered SQL servers, perhaps a web server here and there with a few websites, app pools, and other misc things can, and is, being done with just PowerShell using around 100 different custom modules. Using these many modules in tandem is taking PowerShell to the next level. If you can think of various "levels" of PowerShell, they may go something like this: Shell --> Script --> Module. There's no "bucket" to place any higher-level abstraction in. A module is technically the biggest "bucket" code can go in. But just because a "bucket" doesn't exist yet, doesn't mean it's not possible.
By using several PowerShell modules as one, distinct product, the user can perform thousands of different options and build something that can automate just about anything in an organization.
If you're just starting out learning PowerShell, you're not going to get to this level of automation overnight. It takes a lot of time and effort to break problems down, figure out how to structure processes and finally write all of the code inside of the modules.
With Microsoft's backing, PowerShell has become a standard in Azure and in Windows environments and has gone far and above what VBscript and batch files ever could have imagined.