In defense of complex permissions, this often ends up being necessary to avoid single points of failure. For example, if someone can turn off the setting preven

In defense of complex permissions, this often ends up being necessary to avoid single points of failure. For example, if someone can turn off the setting preventing force push to the master/main branch, that person should not be able to commit code thereby requiring more than one person for a commit to be force pushed in practice. Even better would be to require a config change like that to be approved by more than one person, but that can be difficult to implement compared to adding in narrow permissions. Even if you just prevent force pushing in general, another common bypass would be disabling CI for certain commits (such as in cases where the CI infrastructure is down and the commit is necessary to fix some ongoing incident). Yes trusting developers is always going to be necessary to some degree, but that doesn't mean absolute trust is required all the time. For your specific example of not being able to see tickets as admin, I imagine that feature was added for teams where sensitive information is stored in the ticketing system for things like user reported issues. User reported issues often has PII or other personal data and while developers need to see that information, admins often don't. When I worked at a bank, any remotely sensitive columns in the database were either inaccessible to developers by configuration or by encrypting them to and from client code when the DB didn't support column level permissions (while Sybase could manage column level permissions, Mongo and Elasticsearch didn't at the time).