For one thing, in EmberZNet there is no such thing. A concentrator is either low ram or high ram. None isn't an option. 
But low ram concentrators have to frequently send route discovery requests prior to sending a message. That's horrible for large networks because these are effectively broadcast messages which can start to degrade a network.
The concept of high/low ram only applies to concentrators. A concentrator (or coordinator) is the hub in the Hubitat world. Whether a coordinator is high ram (full route table) or low ram (partial route table), route discovery can still happen since Zigbee is a self-updating mesh protocol.
Hubs like ST and HE use MTORR (many-to-one-routing) where the only thing a device talks to is the hub, and vice versa... Devices do not exchange messages with other devices. This requires a high-ram concentrator in order to avoid the overhead of route discovery.
What's probably happening, and one of the reasons why many bulbs suck as routers, is because they do not have a lot of RAM and processing.. They are prone to buffer overruns, corrupted messages, and who knows, they could be blasing out a ton of route discover messages (which routing devices can do) causing the network to remain in a constant state of flux.
I would remove the bulbs and see if the peanuts stabilize, then try the same in reverse by adding the bulbs back and taking the peanuts out. It won't isolate a bad device, but will potentially help narrow it down to a class of devices.
