Unfortunately you can't use the Zigbee Network Graph to draw conclusions about the current state of the mesh. The picture displayed isn't always showing routes, and often (unless the mesh is very simple) it's not really showing a mesh map either.
Insofar as getChildandRouteInfo is the source data for drawing the picture, it may show connections to devices that aren't even powered on anymore as long as they still show up in getChildandRouteinfo: often the hub knows a neighbor is unreachable and not sending link status (outCost=0), yet hasn't evicted it from the neighbor table (no need; if there are slots available not enough viable routers to fill them).
Yet the rendered picture doesn't take this into account... @dandanache 's standalone renderer app on which the built-in one is based has a config option to 'retain old links'; however the built-in version doesn't provide this option, it always shows them.
To demo this, try unplugging one of your routers; within 15 seconds refresh getChildandRouteInfo. That unplugged router will be showing outCost=0 -- it stopped sending link status to the hub... yet the picture will still show an orange connection denoting a neighbor link. It will do so until that dead device's neighbor table slot gets filled; no telling when or if this will happen unless you have >16 routers in range of hub.
In reality, the hub has enough info to know not to use that missing device as a router; the app generating the picture doesn't have enough info to stop displaying it.
So in addition to router or child device connections that are currently 'live', you'll see connections to devices that were present in the past. And since getChildandrouteInfo is the (limited) 'window' into what's going on, those connections are based only on devices the hub could reach (1) directly (as a child, or neighbor) in a single hop, or (2) via a past or present neighbor.
That last wrinkle (the 'via') leads to more confusion. To save words, here are more (sorry) pictures:
