I believe FileMaker only looks at the graph when it needs related data, and then it only goes along the path to where it needs to go. I don't think it makes any difference how many extra table occurrences might be connected to the same TOG if they aren't being used at that moment.
On the other hand, I've heard that each TO contributes to load time (when you open the file), so perhaps larger TOGs will help your load time if it means less TOs overall.
There are many different opinions about what is the best way to organize a relationship graph. I would say that the best way is probably the one that's easiest for you to understand and maintain. Personally, I use a slightly relaxed version of "anchor-buoy"–somewhere between strict anchor-buoy and the relaxed adaptation described here:
technically, it might be fine - but You'll lose overview...
If You got somewhere in Your chain a condition depending on a field that has to be set _before_, it's possible that You pick that TO later under circumstances where that field is not set correctly - boom
It's also possible to pick the 'wrong' TO, resulting in deleting wrong items
Therefore, we prefer the anchor buoy method and recommend strongly to go that way
We've found solutions with huge nested/chained relationship graphs - performance in a LAN for users wasn't a problem - but maintaining those solutions was a nightmare
also my recommendation:
search some articles about "Anchor-Buoy".
If your solution doesn't meet your expectations, 'specially when a bottleneck like WLAN-Clients are involved, you might go a step further with the "Selector - Connector" method.