TL;DR: You probably can't tell from a single snapshot of the neighbor table what the trend is... you may need to observe over a period of time to identify stable neighbors and determine if repeaters used as 'vias' fall into that category.
For a good Zigbee mesh, every repeater needs to have a few stable neighbors showing good inCost and outCost figures. And, to effectively extend the mesh as required, stable neighbors need connectivity to other stable neighbors out to the far ends of the mesh.
The only way to tell if the hub has any stable neighbors is to compare several snapshots of the getChildandRouteInfo page over a period of time (minutes to hours). HE provides no visibility into the neighbor tables of other repeaters, but in a typical H/A network virtually every routed message has the hub as origin or destination, so this is the most important table in the mesh.
A stable neighbor will appear in successive snapshots (though not necessarily on the same line of the table) with the same 4 hex digit short ID; meaning it has not left and rejoined the mesh.
It should have low (but nonzero) inCost and outCost numbers. You can safely ignore LQI (LQI and inCost are effectively redundant as a routing metric) and focus on inCost/outCost numbers; inCost is derived from the LQI computed at the hub end of the link (mapped from 0-255 range into a 1-7 figure to save a few bits) and similarly outCost is derived from the LQI seen by the receiver at the remote side of the link. inCost gets transmitted to the remote repeater and outCost gets transmitted from the remote repeater during the periodic link status exchanges. Lower cost paths get picked in preference to those with higher numbers (link costs are summed for multi-hop routes). Zero cost figures essentially mean 'no cost data exists'.
There will always be a few nearby repeaters that are borderline in terms of link quality; those will be the ones that pop in and out of the hub's neighbor table when you look at it every few minutes. Focus on the ones that remain in the table on a extended basis (hours or days apart). They will be the key repeaters for the hub and you want to see the best inCost outCost figures there. In my own mesh, the neighbor table's always full but only 8 repeaters are always present.
In addition to having stable neighbors with good inCost/outCost, they also need to be the ones that are useful in extending the mesh-- meaning they get used as 'first hops' in routing messages to the devices at the edge of the mesh. To determine that, you need to look at which repeaters appear as 'vias' in the route table entries. You can have a boatload of stable neighbors with good cost figures near the hub, but still have a scenario with a bunch of devices on the fringe of the mesh that must rely on a marginal neighbor that is the only one within their range.
This problem can be trickier to solve, since HE doesn't provide access to the other repeaters' neighbor tables; for that you need a mesh mapping tool like XCTU with an Xbee or Digi Xstick. But you can assume you may have issues if the 'via' repeaters that appear in the Route Table Entry section don't fall into the 'stable' category, and don't have low inCost/outCost numbers. Since this table isn't static (and depends on which devices are generating traffic at a given time) this is another case where repeated observation is necessary.
Looking at the traffic represented in the Route Table entries of your most recent screenshot, you've got a couple of good repeaters (3DD1 and C9D8) with excellent inCost/ouCost; however, the busiest (E6B7 and 991A) have mediocre inCost/outCost numbers. B89A is borderline, and at least one device, likely Kitchen 1 (null,1BD3) seems to be leaving/rejoining the network (it's appeared with a different shortID in your previous screenshots; Zigbee devices will get a new shortID with each rejoin).
The table @brad5 posted is a good example of what you want to see-- not only a lot of neighbors with inCost/outCost showing 1/1 but also a high number of those same devices actually being used as 'vias'... meaning they're all taking a share of traffic in the mesh.
I can’t tell you how many times I notice one of my lamps not responding to a scene just to discover that someone has turned off the lamp itself. In one or two locations where I have no choice I cover the correspond switch with a safety cover. There are also smart switches designed to be used with smart bulbs but generally I find the $2 plastic cover works fine.
