There already is access control. Only admins can accept patches, for instance (though a bug we've just made a fix for [0] meant if someone else tried doing it the entire patch system for that project would break). Programmatic content-filtering is really the bread-and-butter of Radicle. Ad-hoc content-filtering is a bit harder, but as I mentioned elsewhere still possible.
We store their public key on the machine. They can add (or remove) admins. Every input is signed, and (when relevant) the author is checked for authorization.
Radicle is a full-fledge (fledling of a) programming language, so you can really do as you wish with access control. Here's the module for authorization [0], and in this module [1] you can see an example of it being used.
You're moving the goal posts quite significantly. You started out by saying that there is no access control. Then when shown it has access control you imply it's not sufficient. Then when it's explained that whatever kind you like can be implemented within the current system, you complain that it's not built-in.
Yes, what you specifically want might not be implemented but it's been explained how it could be implemented. Rather than being constructive and trying to explain what kinds of access control should be included by default, you're dismissing the entire project because it doesn't come with batteries included.
Also, access control is hardly one of GitHub's largest features. It's also quite interesting you think content moderation is necessary for a GitHub-like product to be useful at all -- GitHub didn't have issue moderation (as in, deletion) until <6 months ago in November of last year! Moderation of comments and threads came earlier, but it took a long time for them to be implemented. And in their case everything is in a centralised database -- there isn't a novel technical solution required to delete a couple of rows in a database.
[0] https://github.com/radicle-dev/radicle/pull/552