Begin with the domain requirements
Forgetting about why you don't want user-roles and the associated permissions to be dynamic, you need to approach this from the perspective "what does the business/user need".
So, ask yourself:
Does this business have finely grained permission-rules? This is usually true for companies that handle high-sensitivity information; e.g. banks, any organisation with large turnover or a large workforce, etc.
Are permission-rules highly free-form or are they applied from a consistent set of a rules? i.e. does the person's job title dictate their permissions or does it vary from project to project or file to file, et al.
This is a discussion you should have with the business/software owner. During the discussion forget about your implementation concerns, just talk about what his/her company needs.
Then look at implementation
You need to implement the domain requirements of your software in the best way possible for your circumstance. Ideally, you will be able to define a set of user-roles that assign basic permissions and then allow some dynamic permission assignments where needed on-top of that.
If you still can't find a way to implement it without an extremely difficult-to-handle code-base, then simply put the decision back to business/software owner:
"I can either implement your current domain rules as we discussed or I can give you a simplified fixed role-based system. The implications of this are: more development time, more expensive maintenance, etc. What do you want to do?"
Try to keep the discussion to things they will understand; approximate relative lead-times, associated costs, etc.
The simple point is that you cannot make business rule decisions (such as how permissions are assigned) due to an implementation concern. Either model the rules as they are or explain the business-case for changing them; that is, why you think it is in the business's interest to simplify the permission system.