Locks are pretty dangerous. Locks with a long thread sleep are doubly so. The big problem is there are some errors/exceptions that will be caught outside the Rule leaving your lock locked forever. And there are only five rules that can run at a time by default. So if this Rule triggers five times in that one second than none of your other Rules will be able to run because all of your available rule threads are stuck waiting for that lock.
So the first question is what are you trying to accomplish with the lock and the sleep? If you are trying to debounce then see [No longer relevant on OH 3.0+] Design Pattern: Rule Latching. If you are trying to rate limit so the up/down events are processed a certain amount of time apart, see Design Pattern: Gate Keeper. Both approaches are far safer. If you are using JSR223 Python, both of these have been implemented as library modules you can just download and use. See the PRs at Pull requests · openhab-scripters/openhab-helper-libraries · GitHub.
Indeed, you do not need to run postUpdate and sendCommand. Just call sendCommand.
If you do need a sleep, you might need the sleep before you send the command rather than after, in which case please use a Timer instead of sleep.
What are the channels on this device? I had a look at it in the zwave database and am not knowledgeable enough about the command classes to know how they translate to Thing Channels. I assume it links to a Dimmer?