Perhaps I can explain how Fibery works with respect to these (interconnected) issues, and then hopefully it’ll help clarify things a little.
Lookups
Lookups are read-only fields that will show a collection of entities. They actually are very similar to formulas under-the-hood.
At the moment, they are only able to be shown as lists on entity view, so the features that are available for standard relation views (sorting, colour-coding etc.) are not available. This might be improved soon 
They are ‘one-way’ only. That is to say, if you have the databases A → B ← C (where → means one-to-many) creating a lookup in A to get all the Cs from its Bs does not affect C in any way.
As you discovered, if you want to see As in entity view for C, you need to create a ‘mirror-image’ lookup.
Smart folders and context views
If you create a smart folder based on database A, you can add any views you like, and they will be context-filtered by default. So you can easily show the Bs that are linked to any given A.
Without any lookups, the ‘routes’ that are available for context filters are limited to those which traverse many-to-many or many-to-one relations.
In the above example (A → B ← C) it is not possible to show the Cs that are (indirectly) linked to A because there is no route from C to A except via a one-to-many relation.
If the relationships were A → B ↔ C, then it would be possible.
If you add a lookup in C (getting the As from its Bs) you now have a direct path from C to A, and this can be used for your context filter.
Relation (context) views
Relation views in entity view are really powerful, and by default, also use a context filtering, following similar rules. However, most of the time, a relation view will show the entities via a direct relation (but it is actually possible to configure them to show entities from any databases where a direct or indirect relationship exists).
I hope this is useful info.
With respect to this:
it’s a rather inevitable side-effect of having a complex schema that there can be many direct and indirect routes between any two databases, but you’re right that it might be an improvement to order them by the number of ‘stepping stones’ in the route rather than grouped by database.
I’ll pass this on to the dev team.