>but nothing that cannot be done better in language repls.

You're thinking on different abstraction layers - sure given a library for runtime X a REPL will be better than CLI, but when you're talking about processes then having functionality exposed via CLI vs Windows way of monolithic apps with GUI only - it's a huge difference for automation/testing/workarounds/re-usability/etc. - and you don't really care what the underlying platform/runtime is.

Uh most of windows is exposed via powershell and can be rn completely from the CLI. .NET, the primary development stack is completely scriptable from the CLI. It's quite powerful. I'm not saying I love the powershell language, I don't. But I don't love Bash either.

I can do all of that with Python, Ruby, Powershell, AppleScript,.....

No need for UNIX CLI for it.

Again you're talking completely different abstraction layers - unless you're saying that you can use a scripting language to use something like windows automation API to click GUI and stuff.

My point is that Windows has a culture of black box monolithic apps with GUI focused (if not GUI exclusive) functionality exposing. Nothing stopping you from exposing stuff like commandlets for PS and composing them to build higher level systems - but people don't really do this - and they do in UNIX systems - things end up being more transparent.

Nothing to do with any shell or anything really - more about UNIX philosophy of small focused apps composed together vs monolithic apps.

When you're developing stuff UNIX approach is IMO way preferable.

Windows is not the only alternative to UNIX, there are plenty of OS out there full of developers.

UNIX, is also full black box monolithic apps with GUI, there is a UNIX world out there beyond GNU/Linux and *BSD FOSS culture.