These points above are indeed good examples regarding "forcing bad practices":
If I have 3 free API calls after the API call, after the 3rd freebie, I can return it and call again for 1 core + 3 more that can branch off again. This is inefficient for BC, yet beneficial for end-users (thus, forcing bad practices since it costs and gives more if we avoid the pre and post hooks).
If a workaround to save API costs would be more work for the user, and costs more for BC, that's a lose-lose. If such a "hole" exists, shouldn't it be repriced for that consideration to make it the win-win you folks want it to be?
User entities are primarily indexed by profileId + entityType - so the singleton API will scale well no matter how many players you have.
That said, if your use case gets more complicated, with say hundreds of entities of a particular type per user (say maybe you are modelling user created towns, that sort of thing) - you could consider using Owned Custom Entities instead. You can define addition, custom indexes for those... keeps those lookups fast and efficient.
In addition, if you end up having >1000 Global Entities, you should definitely look at switching to Unowned Custom Entities. Same deal - you can define your own custom indexes...