When I started dzVents two years ago I wanted exactly that: have the advantage of one commandArray-manipulator (the main script) but still have the possibility to work modular as I (and many others) believe that's a better way of writing code for obvious reasons. So I came up with a very simple approach. Each event script (a self-contained piece of code dealing with a particular event, basically a Lua module returning a table) has a generic set of rules that determines if the script has to be executed
or not. So when Domoticz fires an event, it calls dzVents.lua and that script determines which of your rules defined in your script modules matches with the event. That's it. That's basically all the preprocessing that happens when an event is fired. So, with a non-dzVents approach and working with one giant file, you have the same preprocessing as you still have to determine which piece of code you have to execute given the current event. The only difference I guess is that dzVents has defined a generic declarative way of creating rules (the on-section) that read more like sentences. But it does allow you to create very small pieces of scripts. Modular.
But then, whenever it is decided that your script is executed based on the trigger rules, the true power of dzVents kicks in. It encapsulates almost your entire Domoticz state in a clear and logic object structure (again: still plain old Lua, no magic there) and it does that by providing your script with a
domoticz object (parameter) combined with the actual object that caused the event to happen in the first place. The domoticz object has lots of handy methods and access to all your collections (devices, scenes, groups etc). All objects in these collections (artifacts in your Domoticz system) have a simple well documented interface to interact with them: attributes and methods that are relevant for the specific kind of object. dzVents has knowledge about most of the different hardware types out there and extends each device with the appropriate extensions based on so called device adapaters. Highly modular and extensible.
But all this is done in a
lazy way. It only creates the objects when you need it. If you don't touch a certain temperature device in your code, that device isn't created by dzVents. No processing is done until you wake it up. All this to make sure it doesn't eat unnecessary cpu cycles. (That's why getting a specific device is a function: myTempDevice = domoticz.devices('myTemperatureDevice')).
So, as far as performance it is all optimized but surely it is slower than without dzVents and just one Lua script with a couple of lines of code. But not much. I have a couple of PIR scripts running on my Pi3 system that respond within less than 200ms from the moment the event occurs. And to me that's all that matters. I always said that if it passes the PIR-test then it's good enough. (More often than not my zwave network is slower when it tries to switch on the light but that's another story).
So to summarize, dzVents is a light-weight framework but, language-wise,
just Lua without any magic. It takes an approach that is enough to be both efficient (only execute what has to be executed when you stick to a few simple rules) and powerful as it takes away the need a lot of unnecessary coding.
And to be honest (and I'll try to be modest

), I don't think there are many other domotica systems out there that have such a rich and powerful event scripting system as Domoticz has in combi with dzVents and Lua. And I haven't even talked about what dzVents 2.4 will have (ok.. a hint (among others): easy to use event-based
asynchronous http requests
and post-processing (in your Lua scripts) with just a few lines of code.)