Currently NAM creates a federation object for every Name Identifier format except transient. For persistent federation this makes sense, as NAM must store the Name ID to map it to the User Store object.

For every other Name ID format there are no gains, but only drawbacks. First of all the access times increase, as you have first have to search the AC eDir, and only then can access the user store. Secondly, the object is created per configured provider, blowing up the AC eDir unnecessarily, as any user in the user store can have multiple objects in the AC eDir. Thirdly, this is not documented, so most customers do not know about this and do not take any precautions to accommodate an increased number of objects, and may be surprised if their authentication gets slow.

Finally, in case on configured federated IDP, you cannot change the IDP attribute matching user store. Configure the IDP with user store A. Once users authenticate, the will be matched against user store A and the federation object will be created with a reference user store A.

Now change the matching configuration to user store B. The users that were already authenticated will still authenticate against user store A, even if they do not exist in user store B. The reason is that the IDP looks first at the federation object, see the reference to user store A, and look up the user there. There is currently no officially supported way for an admin to remove the federation object. And most customers will have no idea as to why this is happening.

Therefore I'll submit that the IDP stops creating federation objects except for persistent federations, and instead looks up the user directly in the user store.