(TL;DR: Also note those neighbor table entries showing age:7 with outCost:0; that's an indication they aren't useful for routing to the mesh)
The 'Neighbor Table Entry' section contains info from the most recent link status messages received from up to 16 routing nodes that the hub will consider using to transmit to your entire Zigbee mesh (as the 'first hop' of a single or multi-hop route). Even if you have more than 16 routing devices in your mesh, the hub can use only one of the 16 neighbors currently in its table to get to them. So it needs to track the 'best' neighbors to use based on link status exchanges it receives (and the frequency with which they are being updated). You can get an idea of how robust your mesh is (at least for a radius of one hop from the hub) by looking at the age and cost values in these entries.
When the hub gets one of these messages (routing nodes send them on a regular basis like a heartbeat, even if they have no other traffic-- broadcast every 2 seconds until a bi-directional link is established, then every 16 seconds), the 'age' counter gets reset, otherwise when a reporting interval expires the age field gets incremented. This way the hub can tell when a neighbor's entry is 'stale' should it go offline or possibly its transmissions fail due to interference or network congestion. New entries start at age 0 (and have a 'probation' period where they are allowed a few intervals to provide a cost metric; if they age past three without doing so, their outCost gets set to '0'-- a signal to the hub that they aren't playing along and won't be useful nodes for routing).
Established neighbor table entries get their age counter reset to 3 each time they exchange a message with the hub-- you can see this happen if you refresh the ChildandRouteInfo page. If you see the age increment past 6, that threshold is an indication to not use that 'stale' neighbor anymore... and its outCost gets set to 0; Normally low cost routes are better but 0 is a flag to not use that neighbor for routing. Instead the hub must use a multi-hop route through one of the other neighbors in its table (that hopefully will have the 'stale neighbor' as a viable entry in its own neighbor table-- otherwise the stale neighbor and its child devices may be stranded).
