Your rules need to be written to handle this sort of thing, either by canceling timers or rescheduling timers and the like when subsequent events occur after the first event. In typical code fasion, 20% of the code is functional and 80% handle error cases and edge cases. OH rules are not immune, particularly with such a complicated configuration as this.
This timer should have been canceled on step 4.
Using rule enable/disable is a really complicated way to handle this scenario. Use Timers.
Only these are not robust. And slowing down rules doesn’t make them robust either. Slowing them down doesn’t make them less prone to timing issues, it makes them more prone to timing issues.
Have one rule that triggers when the bathroom door changes to OPEN that turns on the light. Set a condition on the rule to only run when the occupancy is OFF.
Have another rule that triggers when the bathroom light changes. If the light changed to OFF, create a Timer for five seconds from now to set occupancy to OFF. If the light changed to ON, cancel the Timer if it exists.
With this simple approach you avoid all of the above problems. The occupancy will only go to OFF if the lights remain OFF for at least five seconds. Any subsequent events (e.g. the lights changing back to ON) will cause the timer to be canceled and the changing of the occupancy to OFF never happens.
This is a rock solid approach based off of [Deprecated] Design Pattern: Motion Sensor Timer and in fact you could achieve the above using rule templates instead of needing to write your own code. But even if you write your own code, Timers are going to be easier to implement, have fewer side effects, and be more robust than sleeps and enable/disabling of the rule will ever be.