I knew I had to fiddle with some GPOs, and this is where the fun started.
I created a new GPO, applied security to only scope it to this one user, and applied GPUPDATE. It bombed out:
The Details of the same GPO suggests that the user is disabled:
ErrorDescription: This user can't sign in because this account is currently disabled.
I new network connectivity wasn't an issue. I checked DNS, although computer settings were applied successfully. This uncovered a whole heap of inconsistencies which I corrected, however it didn't affect my GPOs. I even turned on USERENV logging - nothing useful in there either, and neither in the GroupPolicy log.
I new the account wasn't disabled because I was logged on with that account.
I was banging my head against the wall. Then I came across a forum where someone suggested to clear the credentials vault.
Checked the vault, and surprises surprise, found the credentials of another user, and yes, that user's account was DISABLED! Enabled the account, and GPUPDATE now reported that the credentials are invalid. Indeed, I noticed Security-Kerberos Warning 14 events in the user's System log to which I didn't give much attention before:
I was getting somewhere.
So apparently, once upon a time, my user had to access another user's resources for whatever reason. However, in time, the other user moved on, his password was changed and the account was disabled. The credentials in my user's Credentials Manager vault were not refreshed or removed.
There was no trace anywhere in any log that I could find of the account in the vault: not in the USERENV log, not in the domain controller's Security log - nowhere. Not one hint.
Clearing the obsolete account's credentials from my user's Credential Manager fixed it: the GPOs are now applying happily.
Takeaway point: GroupPolicy Error 1053 events in the System log with ErrorCode 1331 is likely caused by wrong credentials of another user in Credential Manager. Go check your vault and clear/update anything suspicious.