What you're describing does sound like a legitimate problem... if what is being reported on that page is intended to be a current copy of the controller's view of the mesh, it would contain only functional nodes. If not, a Z-Wave repair (and removal of ghost nodes) should rectify that situation.
Putting that question aside for the moment, the next question is how could a functioning device actually work if it's using a route that includes non-functional or non-existent nodes? That one may be easier to answer.
Let's say a route is built that includes repeaters in the path A-B-C-D; for sake of simplicity these are the only nodes that ever existed in the network. Supposedly when the controller generated this route, it was deemed to be the 'correct' order of transmission through a mesh containing those nodes. Now, if device 'B' disappears (fails or somehow is otherwise deleted) according to the spec, the route will continue to be used until it has been retried multiple times and repeatedly fails.
A Z-Wave repeater doesn't contain any routing table, it doesn't inspect an incoming frame for invalid nodes-- it just pays attention to frames that contain its own node ID somewhere in the routing field. So if node C happens to receive the frame transmitted by 'A' and finds its own node ID there, it blindly retransmits the frame; hopefully the next node in the route also sees it's own node ID and does the same. Even though an intermediate (and currently invalid) node was present in the routing field, it doesn't prevent reception by the next legitimate node in the path, so the transmission succeeds. What would cause a failure in this scenario is node A being completely out of RF range of node C... then the route would fail.
Now as to why the table looks like it does is another issue; one that comes up pretty often and there doesn't seem to a satisfactory answer. One would expect that it would contain the same (hopefully accurate) view of the mesh that the controller is basing its route calculations on.
Regarding Z-Wave routing in general, the veil of mystery was lifted (somewhat) with the release of the Z-Wave Network Layer spec: Z-Wave Network Layer Specification ( Z-Wave Routing ) Released
Z-Wave's routing strategy only uses two methods to generate routes: the front-up method is controller calculated, the last resort method is mesh flooding explorer frames. Neither provides for any optimization over time, nor does it track error rates to determine if it should try another route.
Rather, if the last working route has ever succeeded (regardless of hop count) it gets used/re-tried until it fails, at which point another saved route, if one exists, gets tried and used until failure. If/when all stored routes have failed repeatedly, explorer frame flooding will then be used to discover another which is then saved and re-used. The spec includes a provision to generate arbitrary 'application priority routes' not based on either of these methods, but HE doesn't provide user access to that feature.
So it's kind of simple; calculated routes come from the controller: it's the only device that knows the mesh. Key assumptions of this scheme are: the hub requests (and nodes accurately report) neighbors when topology changes, 'reported adjacent' means 'good RF link', and a 'snapshot in time' is sufficient to generate routes (and backups) which accomodate a dynamic RF environment until another snapshot is taken.
When things fall apart, it's likely that the controller is handing out routes that include non-existent nodes (ghosts); devices have been relocated, so the controller's view of the topology is stale, or the RF environment has changed (new obstructions or interference has changed the neighbor picture). There's also a practical limit to how well neighbor links can be ranked for purposes of generating efficient routes given that a static RSSI value seems to be the only metric available.