Both, Azure CLI and the PowerShell package use the REST API of Azure.
Azure CLI is a PowerShell-like-tool available for all platforms. You can use the same commands no matter what platform you use: Windows, Linux or Mac and it's open-source
The real biggest benefit of Powershell is that it operates on objects, not on strings. Therefore it's really easy to work with the output of commands
You might end up replacing all my ARM Templates with Azure CLI scripts as it is less verbose and easy to read
PowerShell has some significant advantages over CLI:
PowerShell is a language of Azure Functions. So you can easily write a module or code and push it to a secured Azure Function. CLI is not a supported language.
Same goes for Azure Automation Runbooks, whereas CLI is not a supported language.
If you want to orchestrate a hybrid workload covering on premise and cloud, i.e. deploy a Service to a Windows Server and then deploy an endpoint in Azure for it to interact with, PowerShell can but CLI can't (and I would surprised if it did).
If you want to invest in one language that can call legacy Modules for management, PowerShell can but CLI can't.
If you want to create your own DLL in C# or any other language and incorporate that into your scripts. I've had to reverse engineer DLLs and wrap them in PowerShell to incorporate them into orchestrations.
I've had significantly more success extending DevOps pipelines with PowerShell than CLI.
PowerShell has very good multithreaded workload support for scenarios such as Azure unit and smoke testing and large Azure parallel deployments (beyond DevOps parallel tasks which get clunky). TBH, I am not aware of native multithreading in Azure CLI.
I can develop a module, use it in all the above scenarios and then give it to an end client; TBH, I don't believe I can do that for CLI (create a module, digitally sign it and then nuget feed distro).
