There's nothing that would stop you from putting a full blown jira-like UI which interacts with that database. Well... Apart from that UI not existing yet. But in theory, you can have both. With a centralised main head in the same way people use central repository for git.
in large non-tech companies i see a pattern where the company adopts standard open source tools arguably better suited to open source distributed development (many small git repos, github/gitlab) -- but then there can be pressure to present information for ease of central governance and control
at $current_job there's pressure for 100-200 people to use a single jira project so auditing and risk can be done via that one jira project, whereas at the same time there are an increasing number of git repos containing code for different systems (or ci/cd/build scriptery for different systems)
the jira project everyone is forced to use has about 100 different states a ticket can be in (many synonyms) and about 30 different custom relationships defined between pairs of tickets - so it is challenging to sanely encode or track the state of tickets (lowest-common-denominator meaning that it cannot be a fair approximation of the reality of an individual team's process) while also being absurdly slow.
i am not quite sure what my take away is but it is completely non obvious how putting the issue tracking db in a single git repo would materially help any of this. a sufficiently entrenched bureaucracy can destroy the value of any technology...
I think it could actually prevent bureaucracy from destroying the value. They can have whatever reporting, enforced flows, business states, etc that live in the repo. You get all of that info locally - so you can create a minimal, lean interface for only the small part of it that matters to you. One of the problems I had with JIRA where I used it was that it grew into a monster, even though I only needed maybe 3 functions out of it. It could be simplified from my side, but... the API was not exposed because corporate rules and the number of requests that would require to enable, made it useless to try.
There are ways to solve those problems, but yes a good UX team needs to be brought to those problems, and I think that is a big issue. There's lots of little distributed bug trackers that stop at CLI, but few to none that have even attempted a UI, and I've yet to see even a proposal of a full workflow system with non-technical "stakeholders" in mind.
Again, all of that is theoretically possible. (We've got CRDT/OT-based collaboration apps all over the place today.) It's certainly not easy though.
I think the biggest problem is always going to be the "Stakeholder" issue, and just about everyone else is touching on this too. Issue databases solve a number of different problems for a number of disparate roles of people. As much time as developers spend embedded in an issue tracker, you also have PMs, Managers, Executives, Clients, Customers, Testers, and sometimes a panoply (or even panopticon) of all sorts of other "stakeholders" with one reason or several to be in and out of an issue database scattered across a wide variety of technical acumen.
For anything more than a small team of only technical people, one or more systems of reporting (in either direction) becomes generally required. Can Clients or Customers submit new issues easily? Can PMs (or Managers or Executives) get the reports they need? Can Testers accept issues as completed or file new bugs on them?
There's so much more workflow than just the Developer side of things, for better and sometimes for a lot worse. (The "Jira Effect" where nearly every issue tracker eventually seems to succumb to becoming a super-configurable business workflow engine with a built-in CRM and a support desk ticketing system and a hideous kitchen sink with terrible load times.)
There's probably still a chance to find a really good sweet spot for distributed issue tracking that has just the right amount of bidirectional reporting to fill an average development team and their stakeholders' needs, but it's probably going to take a smart UX team to do it. A CLI-only approach seems unlikely to work, again just given the huge swath of technical acumen to be found with fingers in an issue tracking pie.