We do monthly releases, and the level of effort has been under an hour each month per dev, which has been super worth it for us.
Being able to dedicate a tag, field, or work item type is pretty handy.
Ultimately we also decided to go with the tickets, but I am curious what your reasoning was to go that way?
The primary advantage of the ticket-based approach is that it's much easier to involve non-dev stakeholders. I'd choose it whenever other people might want input in the process. Most ticketing systems also offer a lot of flexibility, you could incorporate the ticket name, group tickets by relation, block completion states, act on deployments, etc. The ability to edit the note without rebasing is a major bonus as well.
The git-based approach potentially leads to a more readable commit history, and strongly associates any release notes with the actual code change. On the other hand, it's a pain to edit and can distract devs while they're problem solving if not setup well.
It works really well so far.
We also might need customer facing release notes at some point. But that shouldn’t be in the commit messages I think since it’s irrelevant in that technical context.
A big consideration for us was that we didn't want to get in the way of normal development, and Git is a core part of that loop. By making the release note a thing that happens separately, we let devs batch that work before a release. But the tool displays the commit right as you're writing the note, so you can quickly see what internal-facing commit message you wrote at the time, and copy-paste if you think it's good enough.