The EXE will contain details on how anyone with its possession could then login to the router with enough permission to do damage.
That's simply incorrect. The SSH executable by itself, doesn't let you log into anything. The LNK file containing the SSH command doesn't let you log into anything, it only tells SSH what you want it to do, but without valid login credentials, SSH can't comply. Those credentials live outside both SSH.exe and the LNK file giving the command.
SSH tries these user names:
1. Your local OS user name, if it wasn't given one explicitly. If that's what you used on the MT at well, the user name doesn't live in either the SSH.exe or the LNK file.
2. A user name found in one of SSH's external configuration files, most likely
the per-user config file; again, it's outside the EXE and outside the LNK
3. The name you gave on the command line: ssh user@host COMMAND... In this case, yes, you've put your user name in the LNK file, so sharing that LNK file gives away your user name. If this is a problem for you, take option 1 or 2.
As for the optional passphrase on the key and the key itself, those don't live in SSH.exe or the LNK file, and you can't provide them that way even if you want to, on purpose.
The linked document shows how to protect the external SSH key. The only way to break that protection is to break into the user's Windows account, at which point the security game is over regardless.
My solution would be to have a secure webserver talk to the mikrotik in the background - where the credentials are stored safely, and client has access to a client page to reboot device. This requires more infrastructure setup sure but eliminates a potential security risk.
It eliminates nothing. It only moves the security risk to another machine, then exposes an external interface to that machine.
How are you protecting the user's login on that secure web server, and how is that better than the mechanisms available to protect an SSH private key?