They're likely a sysadmin trying very hard to get around a lot of limitations Microsoft has on their out of box toolsets and to avoid home-rolling a lot of solutions in more challenging languages.
So a combination of C files, executables, and PS scripts is pretty normal for such an environment. The C/.exes are likely because there are usually pretty obvious walls in Powershell once you're reaching the limit of what PS is meant to do; if most of your code is just .NET, probably you should be writing a small .NET app instead of trying to do it through powershell; given that it's not always easy to just execute a PS script on end-user environments depending on the GPOs and other security items, probably the author has just written some very common workflows that were too annoying to do manually, not worth the effort for a fully functional program, but needed more than what Windows returns normally to Powershell.
I'd say the author is on the far end of the Powershell User spectrum, as the tooling is pretty good, and it's clear from the use-cases they list that they are really trying to administrate their Windows boxes very personally but without having to click around the UI a ton. Many of the scripts are just to get around windows' permissioning and access control
Once you've loaded it up, you can use it directly from PowerShell. I've done this in a pinch and then wrapped it up in a normal PowerShell cmdlet to do things that weren't available from PowerShell otherwise and without needing a .NET build workflow, without needing to store .DLLs, etc. In OP's situation that's what I'd be doing instead of building .DLLs.
https://learn.microsoft.com/en-us/powershell/module/microsof...