Adding Node-RED definitely increases the overall complexity, but also increases the overall flexibility.
When I look at OH I think of it as three layers: the bindings (the interface layer); the rules engine (the application layer); and the GUI (the presentation layer).
By moving to MQTT to sit on top of the interface layer, I made it so I can isolate the OH bindings as interfaces and expand the interface layer through other programs. A specific example in my case is that I have an NX584 alarm system. The current OH binding didn’t quite meet my needs so I was able to use a 3rd party interface to map the communication to MQTT (I did it through Node-RED temporarily but will make some tweaks to do it direct to MQTT).
With Node-RED, I’ve pretty much replaced the application layer from OH and also using it as an additional interface layer by replacing a number of the bindings (I use a WeatherUnderground node to replace my WU binding, a timer node to replace Astro, and a harmony hub node to replace harmony binding) and then feed the outputs back into MQTT. I figure going direct through these nodes should improve performance (though I’m sure it’s a pretty minuscule improvement)
Now I’m looking at some MQTT GUI interface tools to potentially replace the OH SItemaps/App which will give me the ability to not have to map back into OH items that I control outside of it (like the alarm system, harmony, etc.) and give me more flexibility:
If all you are looking for is a more visual rules interface, it sounds like this is an interesting alternative: