I think that is going to depend on who is using it, and given that Hugo is still fairly young and basically requires commandline interaction, a lot of folks won’t want to upgrade unless your theme is aligning tightly to their vision for their site. Just as a major benefit for Hugo is that a static binary that will continue working without updating it, themes are as “fire and forget”.
So, it comes down to marketing: how much do you want to work to keep folks up-to-date on what you are building? Enough to keep a mailing list or post in these forums when you have a major update? A changlog based feed?
If I were running paid support or marketing a theme as being an ongoing project where they will always get the best practices if they keep upgrading, I would put more effort into it. I don’t know of anyone doing that, aside from your proposal.
Neat stuff, though! I make my bread and butter customizing WordPress, including themes. In a database-driven CMS updating themes are obviously very important, since they can themselves be secure, but may have deprecated functionality due to the CMS itself being a moving target. The aforementioned static binary nature of Hugo relieves that tension, which makes me mentally wipe the board and see what best practices develop with Hugo.
I think it would be helpful for your project to have a blurb explaining that your theme has special methods for installing, and ensuring that it doesn’t change how most folks expect to install it, name
For my part, I don’t keep themes in my site repo, and instead I clone it on my CI runner at build time. If I am using someone else’s theme I mirror it so I always have a copy (a callback to that npm controversy you mentioned). It also means that my
package.json for my themes are not interacting with my content at all. So from a docs POV, it would be useful to know I don’t need to run a package manager to install your theme.