Thanks, @csteele, for your insight on the internals of HE.
However, there is a little confusion (for me anyway) that I'd like to separate out. Let's use a simple motion lighting process for the example:
motion detected -> detector to HE via mesh -> HE processing -> HE to switch via mesh -> light on
If the processing is done external to HE then the block "HE processing" gets replaced with:
-> comms to external system (via Maker, MQTT, ???) -> processing -> comms from external system (via Maker, MQTT, ???)
Since everything outside of "HE processing" in the first case is a constant, or nearly so, for any given system the external processing time plus the comms time (twice) would be expected, by most people, to be longer than the "HE processing" time. But it's not, at least for most users.*
IMO, this points to inefficiency in HE's processing exclusively. Whatever other loads HE has (getting weather date, whatever) would only make it worse. I'll point out that I have only 30 devices, about 50/50 Z-wave and Zigbee, and my processing on HE is all with the canned apps, no RM, so it's a pretty clean comparison against NR with the equivalent simple flows.
I'm so interested in this timing thing (curse you, @april.brandt! ) that I'll probably setup NR on an Rpi (using NR's bundled install) and test again...but not today. I regret that I did not save the Ethernet packet captures that showed the external, to HE, timing from my previous experiment but I'll do so next time.
*it seems I picked the worst possible "external system" because my response times with HE alone are less than half of what I got using NR. What I setup was NR in a Docker container (don't ask) on a box that I'll just call Server. Also on Server was the MQTT broker. So my external consisted of HE -> MQTT broker -> NR (in the Docker on the same box) -> MQTT broker -> HE. You'll have to take my word for it that Server was more than up to the task and much beefier than a Rpi.