That I can agree with
Yet
Why would you wanna do this?
Isn’t the whole purpose of a interpreted script to be easy deployment?
compiled bash scripts would make as much sense as “object based php programming”
bash and the other unix shells are based on 1970s command line thinking and aimed at a single local machine.
powershell is not. sending a command to 500 or 5000 machines with powershell is as simple as wrapping it in a foreach loop. which you could populate out of active directory or a csv file or whatever equally trivially.
most of the big enterprise hardware and vm vendors are integrating powershell support for management of their gear. already i can do a bunch of remote control of vSphere from linux via powershell today.
see my original comment above for some reasons why, though admittedly this is really niche.
yea but arent you just adding a new layer? e.g.
interpret code -> run programs -> C-legacy’levelish -> assembler.
to
Decompile -> interpret code -> run programs -> C-legacy’levelish -> assembler(and this happens for ALL programs called in the script).
If you wanna run compiled bash’typish scripts C offers the system(someCommand); type and you can compile that right off the bat.
Hell even Java has a bash way of running things in a shell, and read the output.
to me it really seems like a solution seeking a problem.
Why’d add the extra layer to fix a misconception of what a interpreted script is, if you’re affraid of random_haxxor_01 ripping your l33t scripts,
just encrypt your filesystem.
interpreted languages like bash, bat(what ever M$ calls it), power$hell, php, are not meant, and never were meant to run compiled, but ease of deployment,
but really automation really like lets say you like thro have a fleet of computers which needs todo operation X, at the same time.
Not because you need to compile echo “AT+XYZ” >> /dev/modemFile command to your modem.
or copy file X to folder Y.
All this is because regardles of which linux distro(FX.!) you use you can use the same script since bash/shell/whatever is present on the platform.
The end result of doing this, would be you’d only need to deploy the compiler environment on everything you want to use the “script” on from here on out,
AND maintain it, which is NOT why you write a script.
Yeah its just another layer. 
I’m sure theres more uses but none I can come up with ATM. Would it exist if there wasnt demand for it? Who would develop a utility like that if it wasnt useful in some way? Granted the one I linked hasnt been updated in just over a year but still.
The idea of packaging your bat with other programs into a single EXE seems useful enough to me.
Why would you want to use powershell on Linux vs something like Python or Go? (ever in the future)
Yes it is the result of bored programmers.
I have used .bat compilers in one case so far, and that was when adding non-steam games to steam that also needed a second program to start with them (e.g. a gamepad emulator, or older Uplay games where Uplay wasn’t “properly” implemented yet, i.e. uplay didn’t start by starting the game’s executable).
Steam will only accept .exe and .lnk files when adding external games (though I’m not sure if it accepts a .lnk that points to a .bat 
) , so adding a .bat straight away would not work. I wrote the bats just simply starting the gamepad emulator and the game, compiled them and added them. Works perfectly fine.
The same for Uplay games. There are a few different implementations of Uplay in various games. The very first ones when it came out (Assassin’s Creed Brotherhood(?) was the first one I remember) had the issue that when you started the game’s executable they would just die when Uplay wasn’t running, because they didn’t start Uplay with them. A few iterations later they managed to start Uplay instead of the game, so you had to start the game from uplay after that (which… whatever). For the newer games I think it works like steam does, the links don’t point to executables, but to a uplay:// url with a game ID, which starts Uplay and boots you right into the game.
I suppose one reason for them is also to “protect” the code in some way. Like if you share a bat, anyone can fiddle around in it, but if you share an exe it’s not that easy (it’s certainly possible).
One scenario where this might be useful is in businesses where bat’s are used for some tasks that the employees need, but you probably don’t want your wannabe IT pros to mess with your bats. Now sure you can make them read-only when they’re on a shared drive, but you can’t protect them against copy and pasting. Copy the bat, change the code, same issue as before.
So, yeah. There are very few edge cases. But if there weren’t any edge cases they wouldn’t exist.
Well, it’s not like .bat has developed a whole lot in the last year so… no reason to update either, as long as it works.
Also chances are that when CMD is disabled, there’s also a whitelist of exe’s, so compiling won’t get you anywhere.