Not to suggest a totally different path without some thought, but changing the driver would affect the way all apps work, and this may have unintended consequences for some apps — or not (it depends on your setup and what this means for your apps). The default platform behavior is as it is for that reason. Have you considered the idea to use a custom app instead of a custom driver? When subscribing to the event, one of the options you can use is filterEvents: false. This should catch events that the device sends, even if they aren't considered state changes by the platform. See: the subscribe() sigantures docs. This does depend on the driver still trying to send events (and relying on the default platform filtering), but most Z-Wave and Zigbee drivers I know of would. With an open driver like the one suggested above, you could make sure of it, too.
Or you could modify the driver. 
But if your rule is reasonably complex and you have any Groovy (or Java or similar, or could learn) skills, then an app might be an easier approach anyway — and the advantage is that it provides you this option without affecting anything you don't want to work in the way a driver modification would cause. Also, from a practical perspective, the driver developer docs are still being worked on, but there are likely enough app docs now to get someone started who has any capability for this (though this particular driver modification should also be easy if that really is the best option for your use).
EDIT: I'm adding the fact that this is a rarely-used technique (likely for the same reason that most drivers don't work this way in the first place), so you're unlikely to find many examples. However, subscribe() itself is incredibly common, and this modification to that is easy; most of the work would be writing the app code itself to do what you want "action"-wise.
EDIT (again): I may have misunderstood one suggestion above, that being to make the driver retry the command if it doesn't seem successful — not to make the driver force everything to be a state change and leaving the retries to an app. That could work -- or if your device supports the Z-Wave Supervision command class and is paired with S2 (I think that is required for this), you could use Supervision encapsulation for "actuator" commands (on, off, etc.). The driver can retry the command in a few seconds for a few times if the device doesn't get a Supervision reply, and there ares some examples on the forum of how to do this. This technically doesn't tell you whether a state change actually happened, just that the device received the command (or if it never replied that it did), but if the device is working properly, it should almost be the same.
