As with every other security-related question, the first step toward answering this is that you'll need to answer for yourself: what are you trying to protect against?
Security isn't a binary quantity, it's a continuum; or rather, a set of continuums, one for each potential threat. You aren't either secure or not, even against something in particular; rather, you're secure against a given amount of effort in a particular attack. The trick to security (in both the physical world and in computer software) is to decide how much effort you need to protect against for each particular attack, as well as which attacks are simply out of scope. For an example of the latter, it's kind of hard for any software to protect against a denial of service attack caused by someone attaching explosives to the computer and detonating them, so most, even security-oriented, software doesn't try to protect against that threat.
You mention that
Given that its possible to go back through command line history on a Linux machine, I can see how that could be a security problem.
However, that's not the only reason why passing a password on the command line is potentially insecure.
On *nix, anyone who can log on to the system (or more generally, run processes on it) can inspect the system state and determine what processes are running, and the command-line arguments for each. (For example, using something like
ps auxw, or programmatically through procfs.) Unlike accessing someone's saved command-line history, this typically requires no special privileges at all. Processes can rummage around and make it more difficult to determine the command line parameters passed once they are running, but there's still a window of opportunity when the password is available in clear text to anyone for the taking. It's probably possible to tighten things down, up to and including using containerization or jails, but most people who pass a password on the command line probably aren't doing that.
It looks like you can access similar command state in a variety of ways on Windows, including
wmic process get processid,commandline which doesn't require any special tools.
Remember that both modern Windows, and (as far as I know) every *nix there has ever been, are, at their core, multi-user systems. (They do vary in how well, and to what extent, this is exposed to users.) Especially in a shared environment, any reasonable threat model therefore must include an adversary that is able to execute (at least unprivileged) processes on the machine. Once you grant an attacker that ability, there's a good chance that they will be able to inspect process state and derive the command lines that were used to invoke them.
At which point a password passed as a command line parameter is potentially compromised.
That's more of why it's potentially insecure to pass a password as a command line parameter, than simply the fact that typical *nix shells tend to save the command history in their default-distributed configuration.