Please help. I have VRMX1-1LZ dimmers which I understand are Instant reporting as per Lutron patent and so should experience minimal delay when used with smartthings. How exactly do you “include” these “directly with the hub”. I’ve read a few messages from Bravenel where he advises this to be done so you get the quickest response from routines tied to the on/off status of the switch. I’ve currently connected the dimmers to smartthings with standard “connect to” method and for eg using one of the switches to turn on a scene set up in smartthings. There is a variable .5 - 2 sec delay before scene is triggered. I’ve also purchased a VRCPG programmer remote if this will help me include the dimmer directly to the hub. Just want to get the absolute quickest /ideally instantaneous response times in triggering scenes with the switch.
The standard method of connection is the same as connecting them directly to the hub. There isn’t any other option for Z wave devices. It’s only ZLL devices that have an option of connecting via the hue bridge rather than connecting directly to the SmartThings hub.
When you say you have “a scene set up in SmartThings” what do you mean exactly? SmartThings itself doesn’t actually support Z wave scenes. Instead it has its own multiprotocol architecture. You can create logic which has the same end result as a Z wave scene using routines, published smart apps, custom smart apps like core, or the official smart lighting feature.
At present, there is a very odd artifact of the platform where logic which runs locally, such as the official smart lighting automations, may in fact have a greater lag then logic which runs through the cloud. I can think of several reasons why this might be true from an engineering standpoint, but nothing official has ever been said about it. There have been a few cases where people have put in a support ticket and support has ended up forcing an automation which was local to run in the cloud instead to reduce the lag. Which I know sounds bizarre, but there it is.
It’s important to note that even with local devices, there is still an abstraction layer in the smart things architecture. This is why a smart lighting automation, for example, might have a zigbee motion sensor trigger a Z wave light switch. It’s not a native Z wave implementation.
All of which is to say a two second delay definitely sounds like a long time. I would start by reporting it to support and see what suggestions they have. There are some things that might be done to improve the efficiency.
But the one thing you don’t have to worry about is “connecting directly to the smart things hub” – – you’ve already done that. 
The controller that you bought is not going to make any difference in that regard.
I think this is only the case where the dimmer is directly linked to the other dimmers / switches, not with SmartThings (or any other hub) in the middle.
Think about it this way…
Dimmer to Dimmer Link
1 - Press dimmer 1, message sent to dimmer 2 that is 10 ft away.
2 - Dimmer 2 responds within 100ms (or so)
Dimmer to SmartThings to Dimmer Link
1 - Press dimmer 1, message sent to SmartThings Hub that is 10 feet away
2 - SmartThings Hub gets the message and forwards it to SmartThings cloud within (100ms ish) which is ~500 to 1000 miles away from you.
3 - SmartThings Cloud receives your message within (200ms to 600ms)
4 - SmartThings cloud looks at your config / code and decides what to do (100ms)
5 - Sends message back to your hub telling dimmer 2 to turn on (200ms to 600ms)
6 - Hub tells dimmer 2 to turn on (100ms)
Yes, I’ve made up the travel time for the messages and processing time for SmartThings, but you should get from this why it doesn’t happen in 100ms.