Thanks a lot for your reply. I just commented these lines in the rules file and I will see whether this behaviour does not occur anymore.
I followed the design pattern proposed here Design Pattern: Expire Binding Based Timers and I thought that this OFF update might be necessary in order to maintain a consistent internal state of the item. However, if openHab is multithreaded that heavily, it is logical that this might happen and since it looks like a race condition, it is very likely that this is true. However, I don’t see why even in this small piece of code, multithreading should be used. Synchronizing via the item object seems to be really natural to me but it does not seem to work this way.