I have inspected a lot of custom policy examples, and I noticed following pattern: If user is new, we store it locally using AAD-UserWriteUsingAlternativeSecurityId. Do we really need to perform this action? If not, in which case it make sense?
My context is next: authenticate user with given email and issue my b2c token. Later this token with email info inside will be used to query API. I can check that given token was issued by my b2c, and I can trust it. Using nested email I can make authorization.
In my understanding, the biggest benefit is leveraging the Monthly Active Users (MAU) hits. It is possible that if you don't have the shadow account in your B2C tenant, each federated login would count as a distinct MAU.
Moreover, with shadow accounts, your apps will be relying on an Object ID in B2C, so in the future if you allow the user to sign-in with multiple identity providers (gmail, fb, MSA), you can link them all to one B2C directory user (still leveraging one MAU hit), and your app would treat them as the same user, too.
There are far less use cases to why and when you wouldn't want a shadow account in your directory.