Pwsh isn't horrible and the most important part in this case is that it will help bridge the gap until they get more familiar with other more native options like bash or python or such. I mean, given the choice of teaching someone new to the industry bash or powershell, if it were solely about the language syntax and ignoring considerations like install footprint and my decades of personal experience, I would definitely choose powershell. Bash is an ugly and very unintuitive language in comparison to, well, virtually everything else that's still regularly used. (OK, C ranks ahead of that, but mostly for more insidious footgun reasons like memory management, but it's also not a scripting language, so let's ignore that for this discussion.)

I find powershell to be a bit on the excessively verbose side of the equation compared to python/ruby, but that's actually a positive thing for less experienced coders. Bash is quick and dirty, and the short term benefits of quick are often outweighed by the long term detriments of dirty. It's also easier to install pwsh on Linux than bash on windows (ignoring WSL, which is a whole different beast).

That said, OP, you definitely should set up WSL on your local workstation and use that in addition to your Linux test servers and/or containers. You can have multiple different Linux distributions installed in WSL; for a while I had 3 on my work laptop; Ubuntu 22.04 LTS, Debian Bookworm (I think that's 12? I'm more familiar with the codename than number for Debian), and Ubuntu 24.04 LTS. I just nuked the 24.04 distribution recently because I needed to free up disk space, and I still maintain active 22.04 servers while I don't actually have any 24.04 servers. Basically the important thing to know about WSL is that it runs a shared Linux kernel inside Hyper-V and uses a dedicated Hyper-V switch for all the distros. Most changes to WSL instances you can just shut down the instance and relaunch it (through wsl -t <distro>, simply logging out of the session does not necessarily shut it down), but if you're doing things that touch the kernel layer, you will likely need to use wsl --shudown instead, which will affect all running WSL instances. Anyways, Docker is great for testing applications and such, but WSL is like dual booting between Windows and Linux... without actually having to dual boot. And with WSLg, you can even run Linux GUI apps, too, not just stuff that runs in a terminal. The main downside to WSL is that it's backed by VHDX files; those grow dynamically just fine, but they do not shrink. And do not try to configure them with sparse mode, that will quickly lead to data loss or worse. You can access your WSL files from windows via \\wsl$\<distro>\, but \\wsl$\ can't be shared over SMB/CIFS. You can also access your Windows files from WSL via plan9 via /mnt/c/<blah> (adjustas needed for other drive letters, obviously), but plan9 isn't great at performance, particularly around lots of small files. Specifically avoid accessing git repos stored on Windows from within WSL, that's where you will see the bottleneck the most directly, you're better off checking out the repo locally within the WSL filesystem itself. But I routinely symlink say ~/Downloads/ to /mnt/c/<username>/Downloads for convenience. And if you're using WSL, VSCode supports it really, really well.

Speaking of terminals, Windows Terminal is great; it natively adds sessions for your WSL distributions as you install them (although it doesn't autoremove them), and can run PS5.1/Pwsh 7.x, or you can set up sessions over SSH, AWS SSM, or other Azure stuff that I haven't played with, since we're not an Azure shop. Terminal uses a JSON config file and you can even customize the sessions to be organized into folders, although that (currently) requires editing the JSON directly, it's not yet configurable through the settings interface. But once you set it up initially, it's not too hard to maintain, and since it's JSON, you could always just script it. I'm sure there are probably tools out there specifically for that. Biggest downside is that you can't mix elevated PS tabs with non-elevated tabs (pretty reasonable, imo), and you cannot reorder tabs via the mouse in elevated mode, you have to specifically configure keyboard shortcuts to move tabs left/right one tab at a time (why?!). That part still makes no sense to me, apparently they can't do it for some obscure technical reason where the elevation would cause it to crash instead, but it's just absolutely bizarre to me. Not really a big deal, though, just something to be aware of.