No, you created a rule that does something entirely different. Mine turns on the dimmer when the contact senor is opened, then turns it off one minute after it closes. Yours turns the dimmer on when the contact sensor is opened, then turns it off one minute later, and it keeps this "scheduled" off even if you close and re-open it in the meantime (so say you open it at time zero, close it soon after, re-open it 59 seconds after the first time; you'll observe the dimmer turns off on 1 second instead of 60--and that's not all, since you now still have another "off" scheduled from the second opening that may bite you in the future).
Key differences include the fact that this rule doesn't wait for the sensor to be closed (this is a common mistake people make in new motion lighting rules: they schedule an "off" for so many seconds/minutes after a sensor becomes active, not inactive) and that it doesn't cancel these delays and the following actions (here, an "off") when the sensor changes states again. Both of these problems are solved with the rule the way I wrote it, unless this is really your desired outcome--but again, that's a different rule.
EDIT: OK, so I think I should maybe interpret this as the way you think RM should work. You'd still need an equivalent of webCoRE's "task cancellation policy" to eliminate the pileup of delays, I think. I don't mean to debate whether one way is better--but I can definitely say that this is how Rule 4.0 does work, and if you have trouble finding the right triggers or actions, lots of people are willing to help. I'm so used to this now I think I might have a hard time with that way now.