> Would any of the rapid feature iteration and widespread adoption have happened if this theoretical application was _initially_ created as a native app?

Yes. Desktop applications can be just as quick to develop and iterate on as web based ones. Slapping together a winforms UI in visual studio is still the quickest way to get to MVP status.

But how do you manage deployment of a new version? That's where the web comes into its own.

Deployment is definitely harder, but not to the point where it's unmanageable. Click once is one solution that's very common, though not great. It will check a url for a new version at startup and install that version. This URL can be a simple aspx page that gives each user the right version, I recently automated this as part of our CI deployment.

A better solution would be something like chocolatey (https://chocolatey.org/), which is basically a package manager for windows. It doesn't do the automatic updating, but doing that with a remote powershell script should be doable.

For some perspective though, if you automate this as part of a CI builds it should be a once off cost, it's not a justification to make something a web app instead.

There are multiple solutions for handling updates of native apps.

Managing updates to a cluster of backend servers is at least as difficult, because they usually have shared state (a database).

By "the correct choice" I mean the correct choice for a desktop application.

Having a desktop application doesn't mean you can't/shouldn't have a web application. It also doesn't mean they need to look/behave exactly the same.