Well, there is certainly value. Just a week ago the iPhone WiFi presence updated and introduced a bug, and the developer was quick to fix it but had to respond to half a dozen people who had upgraded and tripped the bug.
The approach of banging the http api is clever, but not without its risks. I think the biggest risk to something like this is that your database gets corrupted and people have to clean things up manually... but depending on what apis you’re banging on you might well be able to sort that out too. Deleting is risky...if someone has a lot of time invested in some app config and you nuke the app, a lot of human life just got evaporated.
As for doing work which no one ends up using, I think your biggest risk is that you’re veering a bit from the hubitat green path. Hubitat corporate could well be workin on something like this, and if they do it would be a bad idea to continue using what you built regardless of when than happened to arrive.
I'm just guessing what you're going to need from a candidate package based off what little you've shared. Each package will need a manifest of some sort, and each file in the package will need a magic comment as well. The manifest allows the package manager to install all of the required files, and the magic comment on each file allows you to traverse backwards from file to manifest to check for upgrades.
If that's true, I guess my request would be to keep the requirements simple enough that they don't add to the mental overhead of the project I'm working on. Providing a script which can do the legwork of a release is a wonderful gift as well.
I'm a big proponent of SemVer if you need version numbers.
If you end up needing a magic comment in each file, from the bottom of my soul I ask you to avoid this pattern:
/*** START OF MAGIC PACKAGE MANAGER COMMENT MAGIC
*** END OF MAGIC PACKAGE MANAGER COMMENT MAGIC
Instead, keeping it to one line and straightforward would be easy to script against and not be visually distracting :
// hpm version=12 manifest=url://package.awesome/manifest.json
I'm being a bit hyperbolic here on purpose to balance out my overzealous design direction ...but you asked for opinions so here it is!