Let's use some approximations to 'visualize' the ZWave vs LAN (Ethernet) vs CPU burdens....
ZWave speeds can be 9.6k / 40k / 100k. Using some huge round offs, one could say that 1 ZWave packet at 9.6k uses the same radio bandwidth as 10 packets at 100k and that 40 k is roughly half of 100k. Therefore chatty at 9.6k is 10x as impactful on the ZWave mesh as the same chatty at 100k. Additionally, the radios are half duplex.. if ANY device is sending, nothing else can. That includes the ZWave radio of your neighbors, not just your own collection of hubs and devices. ZWave is small packets with lots of 'processing time' between... mostly as a result of the miniscule CPUs inside each switch or dimmer.
All of the above is a peek into the advice that's given about how-to-build a ZWave mesh. One 9.6k packet run through 3 hops is 40x the impact of a directly connected 100k device. This is where the "put the hub in a central place" and "replace older ZWave devices" comes from. People that do that may not know/care why it helps, but are grinning widely when they see the performance improvement. 
Now... once the ZWave packets make it from Device to Hub and is Ack'd back, the result is "An Event" -- that gets processed by the hub's CPU and any subscriptions to that event get run. All of that runs at gig speeds on a multi-core CPU. Events distributed via LAN at 100meg.. are 1000 times the speed of the best ZWave device. Using similar comparisons, you'd need a thousand Events to use the same bandwidth as a single 100K ZWave device. All of this is why HubConnect seems to have low/no impact on a Hub's performance... Event processing is not a terrible burden.
Summary: IT'S the ZWAVE.
ZWave conversations are half duplex and during that time, the queue's of packets throughout the mesh are held for the next bit of 'clear air'. But, there's a lot of 'clear air' in the protocol, so the dominant delay for the Hub is waiting for the packets to make the round trip, including retries. Your chatty devices are delaying the hub from processing the next packet. That might be something 'human detectable' such as a light being turned on after motion.
Let's imagine 3 ZWave devices on a hub.. a Motion sensor, a Dimmer switch and a chatty Power Plug. Someone walks into a room, and the Motion sensor is triggered. The sensor now has to 'fight' to get it's packet between the chatty Power reports coming from the Plug.. and just as bad, once the hub does see the motion Event, it has to 'fight' to get the resulting action out to the Dimmer. As a human, we are able to step on a Lego as we enter the dark room before the light comes on and the Automation is doomed to be labeled: unreliable.
There are two types of chatty, self imposed and device imposed. Some devices (and the poster boy is the Aeon HEM) are just chatty and there's no adjustment possible. Some devices have the adjustability, but it's been set to send reports every 1% change AND every minute (for example) and that's just shooting yourself in the foot.
My favorite is the Washer and Dryer... yes, we want notification of the cycle being done, but 5 second accuracy is just absurd. Most of us have the announcements repeat for a while because we know the human response is going to be slow. Knowing that the Wash cycle ended 3 minutes ago vs 4 minutes ago is not going to improve the speed at which the responsible person reacts.
For those chatty devices that CAN be adjusted down, that is going to be the biggest impact. Next would be to move them to their own Hub so that the conversion of slow and intense ZWave radio consumption into Events doesn't impact other ZWave queues.
The hub's processor is impacted in the sense of "Hurry up and Wait". The CPU has packets queueing up that can't be processed til the next bit of 'clear air'. While waiting, the Hub's CPU is able to do anything else, but there may not be much else.
Low, in my opinion. The speed of Ethernet, even at a meager 100M, is just so much larger that impact is hard to visualize. The largest LAN impact I can think of has been Weather. Where you get 60 or so Attributes in a big JSON array. It's theoretically possible that many of the Attributes result in Events and thus the Hub is hammered during that 1 second then not again for 30 mins.
