Aha!  More fodder for discussion:

…the identity information needs to be synchronized before the user performs his first authentication.

Why?   Why must identity information be synchronized before the user performs the first authentication?  If a new employee has been provisioned an account at an IdP,  why shouldn’t that person be able to arrive at a Relying Party, and at that time have the IdP advise the Relying Party that (1) the user is valid, and (2) the user should be provisioned into the system?     I don’t see why my example from earlier can’t work in reverse — you batch update your incoming staff updates, but if they attempt to access the system before the batch job is accomplished, the IdP bundles a specific real-time provisioning request into the authentication, and the user is set up and granted access.

To me, real-time back-end data synchronization is needed between silos.  Once you have a single Identity authority with a reach across administrative domains, and once you are doing more than testing possession of a shared secret, you have alternatives.  Perhaps not in every case – but in some cases, perhaps many cases.  Imaginative exploration of these new usage models are what makes this technology so much fun!