Any particular reason why attributes are updated in getDisplayName()?

Thanks @PanCakeConnaisseur for picking this up.
It is already a while ago, so I am not 100% sure why I have put it at that specific place, but I assume I didn't find a better place to trigger the update of the attributes. Where would you suggest to put it?

It makes more sense to update the attributes whenever it is requested. The way you implemented it, each time a display name is read (which might be often), you update the attributes. This is firstly probably very inefficient and secondly might lead to unexpected behaviour.

I think the problem was that by only relying on the "whenever it is requested", it got requested too seldom and the only way to make it update it more often was to call it from the getDisplayName(). Whereas the updateAttributes() function only updates the attributes if there is really a change, so to prevent the database being updated all the time.

I went through the code (Nextcloud's) that is calling the user backend and the problem is that setting an email by a user backend is not supported in Nextcloud. There is also no clean way to inject the e-mail at a different point, AFAICS. I thought about adding something to createUser() to set the e-mail initially but at that stage the user object has not been created yet. I would need to do it later, without getting called explicitly, i.e. store state. This is means there is no clean solution.

You circumvented this limitation by using getDisplayName() to just overwrite the e-mail field if necessary. I don't agree with that solution because it mixes up reading and writing data and is unexpected behavior. I think a trigger that listens for the "created user" event would be a better solution to set the e-mail initially and then allow the user to change the e-mail. Always overwriting the e-mail like you suggested, feels like a hack to me. I understand that it does the job, but this would be better located in an an extra app. IMHO, the user backend should not have any additional logic that corrects or circumvents the behavior of Nextcloud.

I am currently trying to get in contact with core Nexcloud devs to suggest an overhaul of the user interfaces that would allow a clean solution. Until then, I don't think I will implement an e-mail from/to SQL solution.