Person might have been trustworthy when they were hired and they might change their mind at some point.
Even better - they still might be trustworthy but their computer got compromised and someone might be using them.
Maybe some other employee has problems with them and since they have access malicious employee can indicate trustworthy one in some way. Like posting copy of code somewhere online with nickname used by that one.
I know such things don’t happen often but even for mundane things like phone numbers you just don’t give phone number of your friend to a person you both know without asking that friend in first place.
IDK why it's hard for me to explain my sentiment, but I've worked in corp environments with large teams of averages using JIRA vs small teams of smart remote people. In the later my tickets were almost always very clear resulting in 1 or 2 short and tactical meetings per week. In corp environment I have 10 meetings per week spanning hours. The productivity is easily 10x worse.
You are wasting money paying people to write tickets and not read code.
They raise a ticket about the problem they encounter, and then other people triage it and try to find a way to reliably repro the issue, and then it gets passed to the development team when there's something actionable.
I'm happy for them to raise tickets within their realm (and by the way lets not conflate support tickets vs actual work items), but please have some manager sift them thru into something meaningful.
There are very few use cases where I believe read only access to code from people in product, engineering or support should be restricted. Generally the net benefit is well worth the potential risk introduced.
If you are worried about people stealing source code, invest in a DLP or CASB solution. If you are worried about ransom, don’t allow changes without PRs, implement a backup program and harden your endpoints. Not allowing people to do things that helps them understand the systems they work with is a recipe for shadow IT and promotes organizational silos.
To actually answer your question, you can have projects that span multiple repos, but you can't have repos that only have permissions for issues.
In my org, we have a few different repos for documentation + issues related to specific groups and utilize those repos heavily. We also have a couple code repos and anything specific to that codebase is stored there. We use zenhub though as well to help organize / track stuff.