Most apps that do "Login with Facebook" also support "Login with Google" and sometimes "Login with LinkedIn". The backend ownership issue becomes a bit more complicated.

This is even before we get into trust issues most developers would have with Facebook having access to their user data.

The portion of the app that deals with FB data would be hosted at FB, the portion of the app that deals with Google would be hosted at Google, etc. And this is only a problem for applications that pull user data from FB itself, if it was merely using FB for authorization but wasn't actually using any FB profile data, photos, friend lists, etc, than it could all be hosted on a 3rd party server.

So most developers would say "But my FB backend is just a simple proxy / transformation layer that parses the data and sends that to the front end".

Most would be correct - some flows like inviting friends to an app, or showing friends who also happen to use this app (for games, etc.) are so common that they're integrated into the Facebook SDK.

For performance reasons (both on Facebook's end and for the sake of user's experience, just in case his phone moved into a zone with inferior coverage) a fat network request was preferred to multitude of thin small ones - you couldn't really predict when the user would fancy inviting their friends, saving their score, looking at their achievements, or checking out friends who are in same town as them - so a 24-hour cache policy was instituted.