While that's obviously a solution, it's not quite the same y'know? There's a lot more skill overhead in learning that tool vs the comparative ease of the installer project.
Considering how thoroughly MS screwed the pooch on ClickOnce, I was genuinely surprised when they completely abandoned their working installer system.
For small things ClickOnce is fine, but it's a pain in the ass to automate. For example, there's no way to synchronize the 'version' of the installer with the version of the EXE it's installing. I had to hack[1] it so I could pull the version metadata off the EXE assembly and then force it into the XML of the project file where the ClickOnce settings are stored.
There's also no ability to publish the built installer outside of the UI- my build scripts had to build the /app.publish directory and then just copy the whole shebang to a network location for deployment. I'm not as upset about this being a separate step, but if they indeed allow you to configure and deploy the installer from within the UI why not expose an API to do it as well?
Overall I think ClickOnce is fine for internal, self-updating tools. It's worth noting, however, that I was inspired to create my workflow based on looking at what Github was doing with their windows client.
My powershell isn't _great_, so forgive any powershell oddities, but notice how much you have to massage the output of the mage tools to actually get it to do what you want.
Considering how thoroughly MS screwed the pooch on ClickOnce, I was genuinely surprised when they completely abandoned their working installer system.