I think it’s important to understand where speed is critical and desirable. In the context of saving a couple of 100 mS and compared to other benefits.
You have a scheduled event for 6pm .. not important
You log or send a push message when an event happens ..not important.
You walk into a room and the PIR brings the lights on .. important
You approach your house and the door unlocks .. probably not important.
Temperature drops and you bring the heating on early ..not important
You approach your house and the the lighting, heating comes on, not important.
All my automations slow down from 500ms to 5 secs.. problematic
All my automations slow down from 500ms to 50 secs .. disastrous.
My automations fail,. disastrous.
Really the main speed need is is event driven/immediate reaction and typically these are Just motion >lights or switch/button press for lighting. These can be sped up many way, most effectively by direct wireless association sensor > light or using direct hardware. Agreed logic can then not be applied easily.
I venture to say that most people disappearing down the NodeRED Rabbit hole want reliability and repeatability*, not necessarily speed but that’s a bonus. Things must complete in predictable sequence order too, If this is the reason for ‘burrowing’ , and it does appear substantiated , then Hubitat take note as this shouldn’t be the case and it indirectly provides a migration path elsewhere.
*Actually NodeRED offers many diverse and useful nodes and features that RM/HE don’t have which is a big draw too.
