"What if it's both high-priority and hard? Like you find out that a fundamental part of how your product works causes data to be miscalculated in a certain scenario, and rewriting it while maintaining backward compatibility is a multi-week task? During which you will get more high-priority bugs..."
Perhaps it's a matter of terminology, if something is going to take a significant block of time and have multiple people working on it then you need some way of planning and tracking progress, your bug tracker may support project planning as well (JIRA perhaps), but used a pure bug tracker will not be as effective in fixing the problem.
"That said, if it works for your team, go for it. Never throw in more process than you need, but don't assume that what works for small teams scales."
I fully agree with this sentiment, in this case we're talking about a dev team of 6 working in a broader team of 50 developers. So I wouldn't describe it as small, though there again if we were 250 developers then certainly, we'd need more process.
I'm not sure how much team size is relevant here. You're still creating project history through a series of discussions and decisions, things that a bug tracker can record quite well if used properly. Every team also has turnover. Having your project's history recorded in written form can be invaluable for new (and old) developers to research why something was done a certain way, and not have to rely on memory and hearsay to do it.
Perhaps it's a matter of terminology, if something is going to take a significant block of time and have multiple people working on it then you need some way of planning and tracking progress, your bug tracker may support project planning as well (JIRA perhaps), but used a pure bug tracker will not be as effective in fixing the problem.
"That said, if it works for your team, go for it. Never throw in more process than you need, but don't assume that what works for small teams scales."
I fully agree with this sentiment, in this case we're talking about a dev team of 6 working in a broader team of 50 developers. So I wouldn't describe it as small, though there again if we were 250 developers then certainly, we'd need more process.