Most people I give this challenge to fail to account for the complexities of even a simple format like CSV, and typically simply use "grep" to find processes, which would cause havoc with simple user names like "Bob Ash = bash".
For comparison, the equivalent in PowerShell is this:
#require -RunAsAdministrator
$i = ConvertFrom-Csv @'
UserName,ProcessName
DOMAIN\BobJones,explorer
DOMAIN\Bash,notepad
'@
$ps = Get-Process -IncludeUserName
Compare-Object $ps $i -PassThru -Property UserName,ProcessName -ExcludeDifferent -IncludeEqual `
| Stop-Process -PassThru `
| Sort-Object PeakWorkingSet64 -Descending `
| Select-Object `
ProcessName, `
PeakWorkingSet64,`
@{ Name='StartDate'; Expression={ '{0:o}' -f $_.StartTime } } `
| ConvertTo-Csv
It's also a trivial extension to convert this snippet into a "ps1" script that can take formal parameters as input from anything that has those two columns, not just CSVs. And those parameters can be invoked manually, validated by the engine (not code!), and so forth.
What I hope this PowerShell version shows off is just how "neat" it is compared to bash. It's just a pipeline of little processing commands: "get,compare,stop,sort,select,convert". As impressive as your bash solution is, it's... messy. You were forced to write manual loops, use JSON for processing CSV, and do all sorts of admittedly pretty fancy trickery. Ask yourself: Could a junior tech make changes to your script and not break it? Could they even read it? I know I certainly couldn't, and I know more than a little bash!
As to how extensible PowerShell is: More than bash!
The "shell API" is just a byte stream in, and a bunch of byte streams out. That's it.
The PowerShell API is very rich, but it's also very easy to get started. You can simply write scripts or write a "binary module" in any .NET language such as C#. Simply derive from the System.Management.Automation.Cmdlet class, override the processing methods as required, and start writing code. The PowerShell engine will take care of things for you like hooking up input parameters, matching wild cards, expanding file paths, validating inputs, generating error messages in the user's OS language, etc...
In my experience, I can write a "proper" command line tool with all the bells & whistles using C/C++ in about a few thousand lines of code. With modern command-line parsing libraries, it's about 500 lines if I'm lucky. Meanwhile, it's possible to build the equivalent using PowerShell and C# in about 50 lines, of which 40 is just generic C# class boilerplate.