To answer my own question as far as responsiveness goes in another topic,
I setup some simple, and not terribly scientific, response time testing. Since motion lighting is probably the most likely scenario most users will care about for response time I've used 2 different sensors (an Inovelli 4-in-1 (Z-Wave) on battery and an Iris 3326-L (Zigbee) battery only) to turn on a ST plug model IM6001-OTP01.
In both test sets you can see that HE is faster than NR when using MQTT but significantly slower when using Node-RED nodes for hubitat and Maker API. This is different than my test some weeks back but that was with an earlier version of NR where I had to run it in Docker. It was also with an earlier version of the MQTT app.
It makes sense to me that MQTT is slower because there is a Mosquitto broker between HE and NR. But I find it surprising that ANY external system can effect the operation faster than HE can, and by a substantial margin. But this is consistent with what the consensus of HE & NR users has said.
It has also been said that HE would (likely) be faster if one writes an app in groovy for the operation but there are many downsides to that so it is not an attractive option, especially when the Motion Lighting App can deliver 1/3sec response as is.
I did do some less informal, analogous testing with another pair of devices in my home that use the Motion Lighting App with a conditional on lux from a 3rd device and got response times of 1 - 1.2sec. As that was not an appropriate comparison I did not pursue it for the purpose here.
Responsiveness for "time-critical" automations favor Node-RED with Node-RED nodes for hubitat and Maker API in my environment. There are many variables in the hardware and software environment which I can not reasonably replicate so YMMV.
There are many reasons one may wish to use Node-RED along with Hubitat and here I have addressed but one of them.
HE Motion Lighting App avg(314, 331, 298, 302, 287) = 306.4ms Node-RED with Node-RED nodes for hubitat using websocket via Maker API avg(233, 248, 211, 209, 219) = 224.0ms avg(162, 163, 131, 170, 147) = 154.6ms between Ethernet packets avg(071, 085, 080, 039, 072) = 69.4ms processing time Node-RED with the built-in MQTT nodes via @kevin's MQTT app avg(638, 527, 503, 524, 650) = 568.4ms avg(031, 088, 078, 068, 105) = 74.0ms between Ethernet packets avg(607, 439, 425, 456, 545) = 494.4ms processing time
HE Motion Lighting App avg(395, 318, 370, 361, 209) = 330.6ms Node-RED with Node-RED nodes for hubitat using websocket via Maker API avg(208, 209, 245, 198, 226) = 217.2ms avg(161, 140, 172, 131, 161) = 153.0ms between Ethernet packets avg(047, 069, 073, 067, 065) = 64.2ms processing time Node-RED with the built-in MQTT nodes via @kevin's MQTT app avg(519, 500, 598, 490, 467) = 514.8ms avg(088, 077, 044, 078, 078) = 073.0ms between Ethernet packets avg(431, 423, 554, 412, 389) = 441.8ms processing time
All device times were taken from the HE logs. All Ethernet packet times were taken from Wireshark. I ran each test 5 times and then averaged them.
Node-RED nodes for hubitat packet times are from "motion active" message comming out of HE to the ACK by HE of the "turn switch on" JSON packet..
MQTT packet times are from the "motion active" message coming out of HE to the ACK by HE of the "turn switch on" message. Therefore the processing time includes the time it takes for the Mosquitto broker, which is on the same box as NR, to receive/forward (twice) the messages.
The Inovelli sensor is not nearly as sensitive or quick to respond as the Iris (observed visually)
Edit: Oops, forgot to show the flows. Not that it matters much but just to show the simplicity...