Huh I’m sorry, I missed the scrollbar in that timer snippet. It hides the two last lines which actually includes this statement. I apologize.
You didn’t enable the service file as well, right? And it’s also not possible that your job runs longer than the next execution?
No worry. 
Actually I did these:
systemctl enable --now myjob.timer
systemctl enable myjob-sleep.service
(I just thought that’s self explaining when you’re at the point you’re writing your own unit files… 
)
If /root/scripts/MyJob.sh would be executed again under any circumstances (independent if it was the systemd unit or a user running it manually) it won’t make any issues. What MyJob.sh does is protected by it’s own lock files it creates and removes. Meaning: It is okay to run MyJob.sh in multiple instances without interfering each other or at least it would handle this situation itself without harm.
But this actually is not point for systemd or the user, but the script itself - but I think I get what you mean:
Other user may need the timeout settings JobTimeoutSec=, JobRunningTimeoutSec=, JobTimeoutAction=, and JobTimeoutRebootArgument= (and maybe more) to handle this situation.
Furthermore an addition from me: While searching for the exact names for the timeout arguments, I ran over this and I think it would be clever to use this in the myjob-sleep.service to prevent accidentally shutting down myjob.timer by systemctl start myjob-sleep.service:
RefuseManualStart=
(I’ll update my entry above.)
Don’t enable the service. It’ll be started by the timer not the system.
No idea about which unit you are talking, but the myjob.timer will start myjob.service, not myjob-sleep.service .
myjob-sleep.service will be requested by sleep.target, if myjob-sleep.service is enabled. So far my understanding. If I’m wrong, please tell me.
Furthermore please be more precise, e.g. which service you’re talking about. 
(I’m unable to distinguish about which service you’re talking, if you just call it “service”, while we’re talking about multiple .service files.)
I meant the service for the job. My understanding of systemd is now at an end.
Your setup seems very convoluted. Maybe you should take a step back and check how important that job execution really is. However, if the solution above is working as intended, congratulations. 
I don’t think it’s convoluted. My feeling is you’re not reading correctly and mixing things up sometimes. (Maybe mixing up myjob.serice and myjob-sleep.service?)
What I actually want to say is: It seems pretty clear to me, what I built, and how it works together. If any further clarification is needed just let me know!
Last but not least is this above just a >workaround< and not a solution - yes now it works as intended, but not because of correct configuration, but of additional handling the situation - I’ll keep searching for the reason, why Persistent=false is not working as understood from man page nor /etc/cron.hourly/jobs.deny is able to block 0anacron, as mentioned in man page, but for now I’ve time to do so.
Have a nice weekend and thanks for your patience.