My understanding of the assignment and removal process discussed in this article is that the assignment of a role is loosely bound to the user account only by the request objects.
When assigning a role a request object is created that triggers the RRSD driver. When removing a role a request object is created in the same way, instructing the RRSD driver to remove it. That event triggers request objects to be created to handle the resource assignments found in the resource association objects. Every request object that reaches end status (50) is deleted after 7 Days (as stated in the RRSD driver). And that is even true for requests with end dates on the role assignment. End dates on role assignments sets the nrfNextExpiration on the user object and the RRSD driver calculates the time stamp in that attribute (on some unknown interval, I think) and tries to find any role assignments that has passed the time stamp. Any assignment found results in Creation of yet another request object to remove the assignment (status 15).
My guess on the removal process is that the recalculation taking place in the RRSD driver when processing removal request objects is that the RRSD driver reads the resource association object to find the reference to the resource object and finally the entitlement value. The driver then searches through all (yes, i think this is true) resource association objects with the same reference to the resource object and looks if it holds the same entitlement value. If it finds any reference to a resource object holding the same value assigned to the user the recalculation is done (for that particular removal) and the entitlement reference in the dirxml-entitlementref attribute is left unchanged. If the process doesn't find any other reference for the same resource object assigned to the user with the same value the dirxml-entitlementref attribute is changed on the user.