Yes I have to agree, the reference data type is fairly useless because you can’t do anything useful with it. You may as well just store the userId. The documentation for Firestore does explain that queries are shallow by design presumably so that people can’t create these sorts of queries that are effectively like an SQL joins. I suppose this ensues that all queries resolve quickly and they don’t end up with long running zombie jobs on their servers. But as you point out the issue is more related to the network latency from then having to run additional sub calls for each record in your initial result set.
The solution to this is to denormalise your data, storing your user’s name and profile photo link on each post so you don’t need to resolve the reference. But then you need a job to go and update those details when the user changes their name, however this tends to happen infrequently. This is a fairly common pattern with NoSQL databases. It’s also part of the reason Facebook limits how often you can change your name because they have similar problems.