Yeah, using dt to adjust the speed at which variables are modified is great. DT is there so that by saying Add (DT*X) to SomeVar, you can make sure that it is added at a total rate of X per second.
DT returns the elapsed time since the last game tick (basically the last time the event sheet was processed), and it usually hovers around 0.01667 on most 60hz systems (aka 1/60) because Construct 2 uses underlying v-sync related browser timing.
So for example, if you wanted a variable Life to gradually regenerate at 20 points a second. You would say: Add DT*20 to Life. If you test your game on a 60hz refresh rate display: Every game tick, you are adding dt (~0.01667) * 20, or approximately 0.334 life points every tick, after 60 ticks or approximately 1 second, it will have added 20 points to life.
When running same game on 120hz display rate, every game tick, you are adding dt (~0.0083) * 20, or approximately 0.166 life points every tick, and after 120 ticks or approximately 1 second, again it will consistently have added 20 points to life.
So no matter what your frame rate is, dt allows you to maintain consistent value ratios.
Just avoid using dt as a part of a time-dependent condition in an event, so for example, you wouldn't want to have:
Every DT*60 seconds: Add 20 points to Life.
On a 60hz system, dt is 0.01667, so in this case, the statement is roughly equal to: Every 1 second: Add 20 points to life.
But testing on a 120hz system, dt is ~0.0083, so the statement is roughly equal to: Every 0.5 second: Add 20 points to life. Completely different behavior.