That is a good question. It depends on the circumstances and whether or not you're doing highly-regulated and auditable work (medical software, spaceflight databases) or more improvisational free-market stuff (video games, non-essential chat platforms).
Overall, I think my preferred method is to deliberately choose to implement about 15% of Jira's possible functionality but also rigorously define how that functionality can be used used so it's consistent across your entire organization. For instance, Jira has release versions, fix versions, labels, ticket types, summaries, custom fields, etc. However, most of those are really just "other ways to slice the data"., and total freedom allows people to create non-set-complete ways to slice data.
As an example, let's say that I have a list of 400 things--bicycle, pear, jar, cassette tape, ennui, Aristotle, 2. Our Chief Philosophy Officer wants to be notified on any tickets pertaining to philosophy, so he tells our division to tag all philosophy-related tickets as "philosophy" and then starts assigning his own grad students to analyze them.
Well, we just added the "philosophy" tag, implying "a type of label that discusses the academic content of the ticket". Do we have other tags that fit into that label type, like "history" and "science"? Where's the list of possible entries of that tag type? Where's the list of all tag types? Where's the list of all possible tags? What do they mean? Where are they defined? When do I use them? No one knows, because no one has the authority to know, we just keep growing and shipping or else we get the hose again.
By solving a momentary problem--Chief Philosophy Officer wants a set of tickets to look at--we have invented yet another fractious method for looking at an incomplete set of tickets that doesn't actually apply to every ticket, and our Jira ecosystem gets more unwieldy and less complete.
I would instead prefer to either turn the ticket tagging feature off entirely, or I would prefer that the Chief Philosophy Officer not get to dictate what tags are created and instead go through the Tagging Authority Team, which dictates what tags exist, how they can be used, and ensures that all tickets are sortable and categorizable, and well-defined, and self-consistent, and set-complete, and also they version their definitions so you know if a ticket was created under v1.0 of the Jira best-use architecture or under v3.6.
That's why I mentioned earlier that it depends whether or not your team is doing something highly regulated. Anyone who's gone through a detailed software audit from a governing body is thinking either "yeah, we had to deal with this problem" or "man, I should fix our tags". Anyone who can just bang out release versions on any schedule serving any customer would think "that is a ridiculously stupid waste of time, I love tagging anything and forgetting about it, because I only need to worry about the feature for X weeks before we're on to the next thing".
