Sadly, we didn't end up implementing it ourselves. Release notes were a "nice to have" so it became one of those things that gets kicked down the road.

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.

The reason I didn’t go with a ticket-based approach is that we don’t have a perfect 1-to-1 mapping of commits to tickets. The worry was that we would miss commits because they weren’t well-associated. Because the tool we made is web-based, it’s a little less scary for non-devs.