25+ years of working in software engineering has taught me that "issue tracker" presents the wrong metaphor. This product looks like it's not providing any novel improvements on what has failed for everyone so far, other than a slightly shinier surface.
Clearly there's utility to issue tracking: Projects have problems of various kinds (bugs, mostly) that need to be fixed. Sometimes these are conflated with tasks, which are things that people need to do, but those are not the same. Sometimes these are also conflated with "support tickets" from consumers/customers.
The problem isn't having a "database of problems". Clearly that's useful: If I use a program, and it doesn't work in some way, being able to look this information up somewhere is useful, both as a way to confirm that the problem exists for other people, and to follow up on it, and as a way to potentially find an existing solution.
But issue trackers aren't mostly used for that. They're used to drive development, and in that sense, this model doesn't accurately represent the fundamental relationships and power dynamics between people and technology. Issue trackers rot and become unusable piles of cruft very quickly because they're just "databases", and not a process. Databases must be maintained; they model real-life information that becomes out of date almost the moment it's entered. Of course, an organization can use issue trackers successfully, but it requires a very rigid process that constantly follows up, and you end up with a top-heavy social process that mostly (ab)uses a database to keep notes about progress.
I'm a fan of action-oriented task management, based on the principle that if something isn't painful (poses a roadblock to development, for example) or risky (may cause a customer to leave, for example), then it's not worth entering into a centralized database. Project-level task management should be oriented around stakeholders: Whoever an issue is important to should own it and keep it alive.
For example, a project manager can keep a spreadsheet or whatever of what people are working on, and their job is assigning work and making sure things get done, that the work follows some development timeline, and that the upstream stakeholders are satisfied. Nobody downstream needs to see this spreadsheet, but the project manager may need to present it upstream. By doing this, you're essentially rate-limiting your issue/task flow, and ensuring that someone keeps what's important alive. If something slips through the cracks and nobody complains, it wasn't important enough to remember.
A simple document (Google Docs, a wiki, markdown files on Github, etc.) of "known issues" can be used by developers and certain customers/clients to understand deficiencies. It's going to grow stale fast anyway, so prepare for it. Keep it loose and let it rot, and use it as a springboard for ideas in the future (if you bother to ever look at it again). Whenever possible, describe known issues in code so that you can look for TODO comments; that way, they won't go out of sync so easily.
For clients of your project/product, have a support channel ("ticket system"). This is not a database, but a communication tool. Open tickets mean there's a stakeholder waiting at the other end that may not be serviced fully (even if your project doesn't have a formal SLA). Making it public allows people to discover existing problems and find solutions to problems people had in the past. Support channels shouldn't just be for external clients. I think a lot of companies could improve their communications by having internal ones, too.
I think a lot of people understand this, yet it feels liberating to put their backlog in a database, because it seems like something that's ideal for a database. Developers love building task systems; it's such a simple data model that seems to neatly organize real-life concerns. But it's also a model that doesn't scale to more than a handful of issues, and doesn't really match how people work and communicate.
At the same time, it may feel risky to forego an issue tracker. But there are plenty of large projects that are managed without one. PostgreSQL, for example, doesn't have an issue tracker, and bugs are managed entirely through mailing list discussions, and they're doing great.