Unfortunately, you're not really going to know if you are overloading the network unless you go down the sniffer route. I went down that route full tilt.
I've built/re-built my C7 network 8 times from the ground up. 120 devices. As a general rule, each time I got around 80-90 devices, the network would start having stability issues. Didn't seem to matter what the 80-90 devices were. I have very little automation that creates Z-Wave messages. Definitely not overloading the network with automation.
I've learned a bit along the way. In my last go-round, I laid down a bunch of repeaters as the first devices, and then very slowly added devices to the network over a week. With this approach, I was able to build the whole network out, however it ended up loosing stability about a day or two after completion.
What happens (in my network) is that a random device pops a routing error, usually in response to a hail. This in turn causes the hub and the device to try and establish a new route. Given the number of devices I have there are many routes to choose from, so things can bounce around a bit. This process generally hangs transmit on the hub for a short period of time--up to 120 seconds but usually less. This is bad, but in and of itself is not so much of a problem. It just means that further operations are delayed. Annoyance rather than End Of The World.
However, if this happens right before a supervised device sends a message that requires application level confirmation (garage door openers and thermostats in my network) it can grow into a serious issue. If these devices don't get serviced within a relatively short period of time, they fall into discovery mode. 50-100 messages in a brief moment. And if a second supervised device happens to need servicing while this is underway? It results in a swarm of discovery messages involving multiple devices. Bad news for the network. Usually the hub recovers after two minutes, but sometimes requires a reboot to right itself.
For me, the solution has been to move a dozen of the further devices to a second hub. Even though these devices were within 3 hops of the main hub, and worked fine when there were only 50 devices, when the network was fully built out they seemed to initiate a lot of route changes that destabilized the network. Having moved those devices, I've been stable on both hubs for over a week. I hope it stays that way because my wife's tolerance dropped to absolute zero.
As I've said before, I don't think these issues can simply be laid at the feet of Hubitat. The issues appear to be down below, either in the SDK or the firmware of the 700 series chip. Either way, the issues are out of reach of the Hubitat folk. I wish it were different, but it is what it is. I'm sure it's even more frustrating to the Hubitat folk than it is to their users.
Overall, I think SiLabs still have some significant issues to work out with the SDK and the 700 series chips. I hope they do it soon.