It is painful in the mindset of typical unix guy who is used to being able to "just ssh somewhere and vi /etc/something", which is not the way you want to manage large deployments but works even for large-ish ones. On windows there is no real middle ground between use GUI for everything and automate everything.
Also with unix servers various bastion hosts and similar "security measures" are minor inconvenience and usually even supported by automation tools, while on windows this usually ends up being major PITA.
It's been years since I last worked with Windows, but:
1) You can install an SSH server on Windows boxes just fine, then use Putty to SSH directly into PowerShell. PowerShell is not a classical shell, but rather a REPL for a procedural, imperative and object-oriented DSL for system configuration and administration based on .NET, with much saner syntax than my beloved zsh. In short, it works quite well.
2) With PowerShell capabilities - I'm a bit fuzzy on the details here, was a long time ago - you don't even need the SSH server, you can issue remote commands from your local PS instance. It required a bit of configuration up front, IIRC, but then you could replace your local session with a remote one with a single command.
So, in my experience - and note that it was probably nearly a decade ago! - Unix-style remote management was absolutely possible and not that much less convenient. And PowerShell is really a solid tool, with easy access to all of .NET and all of the system; the only annoyance I remember was certificate/signature management, dunno if it got any better.
The biggest pain for Windows remote automation is security around accessing servers remotely, I'll grant you that. I gave up. That's why I have VSTS agents on every box. I can easily write a script and tell each agent to pull the script down and do X locally and insert the results if needed into a Mongo collection. But for the few times I do need to treat my servers like "pets" instead of "cattle". I do everything from the GUI.
There was a time when our net ops team did something and I couldn't Remote Desktop into a server to do something urgent and if course I couldn't just SSH into it where I had to write a quick Powershell script and deploy it via VSTS to make a change. It was ugly.
On the other hand the PITA-ness probably isn't that much caused by the OS itself but by it's historical security track record and mentality of ops and security teams that is caused by that.
We have three different different AD domains - one on prem (well at colo center) and two separate AWS environments. Getting them to be friendly with each other isn't possible. Since the local VSTS agents poll and only need outbound connections, I don't have to deal with firewall issues or domain issues. Also, I can run a script in parallel across as many agents as I want to. You can have as many concurrent agents running on a VSTS account as you have MSDN licenses.
Besides, I already have sane deployment groups and tags defined by server environment and function. I might as well leverage them.
Also with unix servers various bastion hosts and similar "security measures" are minor inconvenience and usually even supported by automation tools, while on windows this usually ends up being major PITA.