@Quentin has already explained it well but I might add another couple of points, some examples, and direct you to a blog post and documentation that might help you discover more detail.
I think the complexity around SAS 9 metadata security comes from the interplay of 3 different things: the type of access control (ACT or ACE/Explicit); the object inheritance path, a set of parent objects, any of which may have had access controls (of either type) applied, from which the object of concern may indirectly inherit; and the identity hierarchy, a set of groups the user is a member of (including nested groups), which may have been used in access controls anywhere in the object inheritance path. All of those 3 things plays a role in determining the precedence of access controls and permissions. As already mentioned, a green checkbox means the direct setting comes from an ACT, applied directly to the object of concern. A white checkbox means the direct setting comes from an ACE (explicit permission) applied directly to the object of concern. A grey checkbox means it is indirect - it may come from an ACT or ACE on a parent object (inheritance path), or it may have come from another ACT or ACE on the same object but from a parent group (identity hierarchy).
I thought some examples might help in trying to further answer your question on why might you change a green (ACT) or grey (Indirect) allow to a white (ACE) allow? As Quentin said, it would be to add a higher precedence permission. You are more likely to change a green/grey deny to a white allow but it is possible to change an allow to an allow too:
Example 1 (replace grey tick with white tick): if you have a grey (Indirect) ReadMetadata grant for the SAS Administrators group on an object you might change it to a white (ACE) ReadMetadata grant on the basis that someone (maybe you in a later step) was to add a white (ACE) ReadMetadata deny for the PUBLIC group on the same object. In the absence of the SAS Administrators ACE grant, the PUBLIC ACE deny on the same object would have higher precedence than the SAS Administrators Indirect grant. Every member of the SAS Administrators group is a member of PUBLIC too, so we add the SAS Administrators ACE to override the (future) PUBLIC ACE and ensure SAS Administrators maintain access. NOTE: that if you were to do it the other way round and add the PUBLIC ACE deny first you would then see the SAS Administrators checkbox was now grey (indirect deny from another group in the identity hierarchy) and so you would then be changing a grey (Indirect) deny to a white (ACE) grant for SAS Administrators group. For this strategy (wide deny, narrow grant back) I would actually recommend doing it through ACTs rather than ACEs - see the golden rules mentioned in the blog post below.
Example 2 (replace green tick with white tick): This one is more contrived, and not something you would encounter if you follow best practices, but it does show what is possible and if it is possible then it needs to be understood and potentially handled. To set up this example create 2 groups, Group A and Group B, and add the SAS Demo User as a direct member of both groups. Now create 2 ACTs: Grant A and Deny B. In the Grant A ACT add Group A and grant ReadMetadata, then in the Deny B ACT add Group B and deny ReadMetadata. Now create a top level folder and apply both the Grant A and Deny A ACTs to that folder. In the Authorization tab for that folder you will now see a green (ACT) grant for Group A and a green (ACT) deny for Group B. Now to visualize this, add the SAS Demo User into the Authorization tab and remove the automatic white (ACE) ReadMetadata grant for them. You will see a grey (Indirect) deny for ReadMetadata due to the conflict in the 2 ACTs. Now go to the Group A entry and tick the green (ACT) grant to add a white (ACE) grant (the example we are after). Go back to the SAS Demo User and you will see the grey (Indirect) permission for ReadMetadata is now a grey (Indirect) grant due to the higher level precedence ACE you just added. As I mentioned, this is a contrived example and if you follow best practices (the golden rules) and only ever deny permissions to PUBLIC or SASUSERS then this type of scenario should not occur.
I hope these examples helped. I would thoroughly recommend reading a blog post by @DavidStern at https://communities.sas.com/t5/SAS-Communities-Library/Which-SAS9-Permission-Wins/tac-p/560050 which contains links to other helpful articles. It also steps you through a great flow chart from some older SAS documentation that I have found very useful when trying to understand tricky permissions issues where you might get an effective grant when you expect an effective denial or vice versa.
Finally, if you ever find yourself trying to debug these issues on a regular basis my company has some commercial add-on software for tracing and understanding SAS 9 metadata permissions: https://platformadmin.com/blogs/paul/2016/03/tracing-permissions-sas-metadata-security/
