You have an X/Y problem created by skipping over analysis of the process problem in favor of a tools-based approach. JIRA and GitHub Issues are tools, not processes, so until you fully define your process flow you will remain at disadvantage.
You need to define what you are tracking, why you are tracking it, and how you will use the tracking data to make work visible. As long as the team and the organization all agree on how this is being done, and what it's communicating, either approach can work.
As a general rule, only improperly- or prematurely-closed tickets should ever be reopened. All other work represents new work with its own scope.
What Are You Tracking?
You are conflating "issue tracking" with "work tracking." They are never the same thing, although they can certainly be interrelated. Whether you reopen tickets or create new ones really depends on what you are trying to track, and how you plan to use the metrics.
You should strive to ensure that your process conforms to one of CodeGnome's Laws: "No Invisible Work, Ever!" Whichever approach you take, it should be clear what work is in progress and how much effort is involved. The status of the work should be clearly visible, and the process should remain transparent to stakeholders.
Opening new tickets ensures that all new work or rework is treated as a first-class tracking item. In particular, it prevents rework (whether from bugs or iterative development) from being buried as invisible work inside reopened tickets, or from inheriting legacy time/effort estimates that don't apply to the current work required.
Most ticketing systems, including JIRA and GitHub Issues, allow for tickets to reference or link to other tickets. When possible, I always recommend that any new work or rework be assigned a new ticket and a new estimate, and then link to any legacy tickets that might be related.
While there can be other reasonable arguments, from an agile perspective a ticket should only be reopened when it turns out the closure was premature because the work on the ticket didn't meet the "Definition of Done."
If a ticket meets the team's Definition of Done, but regressions are found later or requirements have changed, then this is work that was not within the scope of the previous ticket. The ticket was properly closed; the bugs or additional scope represent additional effort required from the team to meet a new objective.
While not exhaustive, here are a couple of simplistic examples to help you think about the functional difference between new work and incomplete work.
- A ticket to embiggen a widget was closed as complete, but the integration testing was not done. This ticket should be reopened and the remaining elements of the Definition of Done should be performed.
- A ticket to ensmallen a dongle to fit a new Model B Widget was closed as complete after meeting the Definition of Done. However, no one realized that the dongle needed milled edges to fit the new model. This specification change is new work, and the work should have a new ticket even though the ticket can be linked to the "Prototype the Model B Widget" story.
- A customer tickling feature was added to your product. However, 12% of your customers are being killed from ocular stabbing by the feathers' quills, and this issue has been classified as a low-priority bug by the sales team. Locating and resolving the source of the bug is new work that requires a new ticket, and should become a first-class tracking item. This ticket should then be prioritized appropriately by the Product Owner (or similar project role) and scheduled accordingly.
Tickets should only be reopened when they shouldn't have been closed in the first place. All other work represents new work with new scope, and should be treated accordingly.