I think your opening sentence is simply false; nearly everything on Windows can be automated these days, and usually without much pain. The real problem right now is that the WMI/WSH stacks, and the PowerShell stacks, overlap, but not completely; the right way to automate something requires knowing a lot about the old Windows automation stacks, and the new ones.
Let's take your example. The only reason it's shorter on Unix is that most Unix systems have programs called "zip" and "unzip". That's legitimate, but if we looked at e.g. modifying DNS, tweaking folder permissions, and a lot of other things, the PowerShell and bash/sh ways would be much closer. I'm not going to argue that PowerShell is a great language; I've been pretty public about hating it. But this isn't about whether Windows can be automated.
The real issue is that, for any given task, there's an easy way to do it in either the old COM-based WMI/WSH system, or in the PowerShell system, but not always both. Since we're on the topic of zipfiles anyway: the way I'd actually make a zipfile from a script would be to bust out the ol' "Scripting.FileSystemObject" COM object, which lets you pretend a zipfile is simply a folder, and which is merely a "$fso = New-Object -ComObject Script.FileSystemObject" away in PowerShell. One that bit us at work last week in a more real-world situation is that, while nearly all of Hyper-V is controlled via PowerShell, the network connection sharing settings are only available via COM interfaces, so allowing your Hyper-V machines to talk to the world still requires a trip back to the Windows 2000 administration handbook.
This stinks, and it needs to be fixed. I'll even grant that the situation might be worse than on many Unixes. But it's also totally automatable, and I'm not convinced that it's dramatically worse than other systems I've had to administer.
Until you have to cope with the fact that you have: Powershell cmdlets with their own specific behavior - mostly standardized; COM components loaded from Win32 - major pain in the neck - you basically need a huge brain to really understand all those rules and quirks; AND old school external commands - where all hell breaks loose since on Windows they couldn't standardize even the freaking exit codes (!0 is bad, fools, as Mr. T would say :) ). Yes, Powershell is usable, but it's really hard to write secure, reliable, maintenable scripts with it...
Let's take your example. The only reason it's shorter on Unix is that most Unix systems have programs called "zip" and "unzip". That's legitimate, but if we looked at e.g. modifying DNS, tweaking folder permissions, and a lot of other things, the PowerShell and bash/sh ways would be much closer. I'm not going to argue that PowerShell is a great language; I've been pretty public about hating it. But this isn't about whether Windows can be automated.
The real issue is that, for any given task, there's an easy way to do it in either the old COM-based WMI/WSH system, or in the PowerShell system, but not always both. Since we're on the topic of zipfiles anyway: the way I'd actually make a zipfile from a script would be to bust out the ol' "Scripting.FileSystemObject" COM object, which lets you pretend a zipfile is simply a folder, and which is merely a "$fso = New-Object -ComObject Script.FileSystemObject" away in PowerShell. One that bit us at work last week in a more real-world situation is that, while nearly all of Hyper-V is controlled via PowerShell, the network connection sharing settings are only available via COM interfaces, so allowing your Hyper-V machines to talk to the world still requires a trip back to the Windows 2000 administration handbook.
This stinks, and it needs to be fixed. I'll even grant that the situation might be worse than on many Unixes. But it's also totally automatable, and I'm not convinced that it's dramatically worse than other systems I've had to administer.