I am not exactly Windows biggest fan, but one of my pet peeves is talking to a Unix developer who assumes that Windows doesn't do something because it doesn't do it how Unix does it, or who blindly assume that the Unix version is superior by definition of being Unix.
Windows has had programmability for a long time. In Unix, programmability means programs that eat text and generate text. On Windows, it means COM objects. Specifically, most programs--everything from big, end-user focused ones, like Word and Excel, to server components like IIS, to low-level stuff like the Ethernet configuration--is exposed through COM objects. While this was consumable from C++ and Visual Basic since Windows 3.1, Microsoft provides the Windows Script Host, or WSH, since Windows 98 and Windows 2000 (with optional installs back to Windows NT 4 and Windows 95) that allows trivially scripting them using much simpler languages. Specifically, two languages come by default (JScript and VBScript), and plugins exist for every traditional Unix language I can think of (Tcl, Perl, Python, Ruby, and even PHP). You can also use any language that has COM bindings (most of them) to use these interfaces if you don't like what WSH provides.
Is this different from Unix? Yes. Is it worse than Unix? That depends. You can have strongly typed rich data, which is a big improvement on text streams for bigger workloads. You can trivially interact with running applications, which is something that is intermittently available on Linux through DBus, the use of SIGUSR, and the like (program-dependent). You can easily work with data that are not trivially represented by text, like nested dictionaries. On the flip side, I do understand that COM and DCOM are more complicated than text streams, but I think that's a trade-off, not an immediately gimme.
Now, the one thing annoying here is that WSH is based on COM, whereas most modern Windows is based on .NET. .NET allows a much richer object system than does COM, so Microsoft replaced WSH with PowerShell so that users could still use a common scripting language, but easily work with the .NET type system. bash/Cygwin would not have been an appropriate choice here. Modeling PowerShell on those systems was; if you look at the language, you'll find it takes heavy inspiration from traditional shell scripting languages, including bash and Perl, but it differs again due to the focus on objects v. text.
So no, it is not fair to say that Windows is not programmable. I also don't think it's obvious that forcing bash to play nice with Windows would've been better than PowerShell, which would've either resulted in giving up a lot of Windows programmability, or forking bash to work better with the Windows way of doing things--neither an improvement.