As for inferior, for what's wrong with it--well, let's start with the easy stuff. The language is not designed to be exploratory and is really hard to write off-the-cuff even when you know it cold. It inherits from .NET in ways that make it actively difficult to type on a REPL (as that's all a shell is). I like .NET, but the BCL is not the right tool for the job and none of the tooling built around PowerShell can compensate for just not being easily written out when I'm exploring a problem by hand. I know PowerShell probably better than most people who use it every day--I'm not an expert but I've studied it at length and used it on the regular for nontrivial tasks--and I can't think in it on the fly. It's a worse solution to a solved problem, for my money, and I'm fairly convinced it was designed to be an RPC layer for GUI apps rather than a way for a skilled and knowledgeable user to interface one's brain with the metal with as little trouble as possible. And that's fine, but that's worse with regards to the things that I care about.
As for substitutability: this should be obvious. I can't substitute it because it isn't interoperable with literally everything else in the stack. It is Microsoft for Microsoft's sake and incompatible with the rest of the non-Microsoft universe in ways that, it must be noted, Apple did not do; while they have proprietary tools in their environments I can still use it with the bog-standard tools that exist on every other Unix machine I ever touch.
PowerShell is supremely explorable. All you need to get started is knowledge about a few cmdlets. Get-Help, Get-Member, Get-Command and Get-Alias then you are in business.
There is nothing about PowerShell that cannot be discovered through those 4 cmdlets.
If you frequently need to dig down to .NET you are doing it wrong.
Contrary to your previous assertions, PowerShell was designed for REPL from the outset, and it achieves that much better than any Unix/Linux shell, bar perhaps fish.
PowerShells commands (cmdlets) are inherently rich on metadata. You cannot create a cmdlet without exposing metadata which is then used by the shell to drive automatic type coercion, syntax charts in help as well as tab completion.
It is so intrinsic to the concept, that you'll automatically get tab completion for your own functions, and even for your own script files.
PowerShell was definitively NOT designed as an RPC layer. You claim to "know PowerShell probably better than most people", and yet you are unaware that PowerShell was specifically designed as a hostable engine.
It is hostable precisely because Microsoft wanted to have reusable script engine which could be used in-process (!) in administrative GUIs.
Unlike traditional shells, PowerShells cmdlets share memory space with the host (the shell when used as REPL) because it SHOULD NOT use RPC to manipulate objects.
You frequently use "appeal to authority" arguments, but the substance of your posts gives you away. You are certainly no expert on PowerShell.
What does 'not designed to be exploratory' mean? How many scripting and shell languages have the introspection that comes with PowerShell, from .NET reflection to simple abstractions like 'Get-Member'? How common is a prescribed and thus simple to discover naming convention such as verb-noun?
I would love to see it in other ecosystems, and the prediction that PS could go open source, along with the recent open sourcing of .NET core and CoreCLR gives me hope.
It's not about the commands. Names, whatever. I learned GNU and BSD command sets cold, names and obscura are not a problem. It's about the experience of using the thing. Everything is so insanely verbose, except when line-noise symbols are injected to break up the monotony, and the editing environment for actually using it is absolute garbage compared to either bash or zsh's emacs/vim modes. You are stuck writing long, complex (not complicated, but complex) commands that can't be easily factored down, with an interface that isn't doing much to help you (and isn't good at the little things besides, ISE is unacceptable compared to a decent terminal emulator like iTerm2). And so iterating--exploring your problem space is unreasonably difficult compared to everybody else in the same space.
A shell is a REPL. If your language makes actually writing things in that REPL hard, it is definitionally bad at Shell Stuff. I find it significantly easier to write code in C# and then transliterate it to PowerShell than to actually write PowerShell. That's a disastrously bad situation for a shell.
You were called upon to give some examples. Yet all you offer is more hyperbole. One is beginning to suspect that despite your assertion that you "know" Powershell better than most who use it daily, you are actually just a troll.
Yes, I am calling you out. I am challenging you to provide concrete examples where Powershell has less discoverability than bash or zsh. I am challenging you to explain why ISE - an environment designed specifically to combine REPL with script authoring - is "unacceptable".
And please, no more hyperbole or condescending remarks.
I learned Powershell mostly from Get-Help. I can usually figure out where to look for a command based on the naming conventions - essentially (one of x verbs)-(one of x nouns). They aren't always fantastic, but for example, Select-String is a little more obvious than grep.
As for substitutability: this should be obvious. I can't substitute it because it isn't interoperable with literally everything else in the stack. It is Microsoft for Microsoft's sake and incompatible with the rest of the non-Microsoft universe in ways that, it must be noted, Apple did not do; while they have proprietary tools in their environments I can still use it with the bog-standard tools that exist on every other Unix machine I ever touch.