Scenes run as jobs in the Vera core, so they are subject to Vera’s scheduling of the job in relation to other jobs, and thus might be affected in ways we cannot easily externally determine.
Reactor runs actions on devices individually, in the executing thread of the Reactor core. Thus when Reactor decides to turn on a light, the action is invoked to do that right now. This is one of the things that can make Reactor Activities more responsive than native Vera scenes.
That said, both will have this limitation: if the implementation of the device action specifies that the action is to be performed in a job, then that job will be queued and run when Vera is good and ready. This is a decision made by the implementation, so for plugins especially, the author should have good reason to use a job rather than an immediate run. YMMV.
I’ve contemplated “device sets” for Reactor, but the technical problems in doing it in the current Vera device model don’t point to a fair exchange of value for effort. Determining what to do on a non-homogenous set of devices when you invoke an action on the set that not all of the member devices support directly, for example, is not a trivial task. That is, if you have a set with a light and a thermostat, what does “turn off” really need to do? There isn’t a universal “turn off” action in the Vera/UPnP device model. If you start building metadata to map such generic actions into the actual UPnP actions, what happens when the set contains a device that’s not in the metadata? On day one, does the metadata need to contain information to support every device and service created by every plugin currently in the Vera App Marketplace? I just don’t see a great exchange of value for the effort this would take. And I have considered it, because Reactor already has a pretty big catalog of metadata even for what it currently can do. But this a whole new level. And then there’s matter of the upcoming new firmware working completely differently anyway…