That makes sense, so does doing releases by using tags, why would that make you uncomfortable?
What doesn't make sense, is creating a completely new language/framework/package manager and decide to place the package registry burden on someone else.
Tags are not immutable.
It's true they're both refs inside git, but git literally treats them as "shouldn't move", unlike branches. They're not immutable in the technical sense, so I guess you're technically right. But they're not used the same way as branches, and the tooling won't like that either.
Tags are not immutable.
This is even in GitHub's docs: https://docs.github.com/en/actions/reference/security/secure...
> Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps mitigate the risk of a bad actor adding a backdoor to the action's repository, as they would need to generate a SHA-1 collision for a valid Git object payload.