If your Xiaomi devices are end devices (not repeaters), and they are now child devices of other Zigbee routers (the Ikea repeaters you added), you shouldn't expect to see them in the output of the hub's GetChildandRouteInfo page. That page is hub centric and will only show the hub's child devices as well as the neighbor routers that it is currently using (only links that the hub is currently using or has recently used will be listed in the Neighbor Table entries).
You won't see every device in your network listed here, nor the path through every repeater that will be traversed when the hub talks to a device-- although that information is gathered and maintaned by the hub (from prior Many-to-One route requests), it is not displayed here; there are tables internal to the hub where that info is stored.
That's because the GetChildandRouteInfo output isn't intended to show all the routing information used by the hub. It does show a list of child devices joined to the hub, and the status of the currently used neighbor routers. As the Silicon Labs EZSP reference states, "A neighbor table entry stores information about the reliability of RF links to and from neighboring nodes". That's the intent of the neighbor table entries shown here.
This type of info (child devices and link status to neighbor routers) is maintained by every Zigbee repeater. If you had the equivalent GetChildandRouteInfo output from every repeater in your network, you could use it to construct a complete map of your mesh. But again, all you get from hubsipaddress/hub/zigbee/GetChildandRouteInfo is the piece of the mesh with links to the hub.
Depending on the timing, you may spot a reference to a child end device in one of the Route Table entries (which show which of the neighbors is the 'next hop' of the route to that device). But as those entries get re-used and aren't static (and are only a piece of the routing logic) you likely won't see all your devices here. If things are working well, its possible that all of those entries could actually be blank (as the necessary source route info would be coming from internal routing tables) and all would be well.
The best step-by-step explanation of what is really going on under the covers (re: how Zigbee messages are routed) I have found is here. https://www.silabs.com/content/usergenerated/asi/cloud/content/siliconlabs/en/community/wireless/zigbee-and-thread/knowledge-base/jcr:content/content/primary/blog/what_logic_does_the-cIRv.social.0.10.html Bullet point 6 is where the Route Table Entries would come into play (and only after other sources of stored routing information have been tried).
