This is true, but jobs offer so much more than this. It's possible, via cooperative scheduling, to suspend and reenter jobs according to various events such as incoming I/O or specified delay times, or a call which explicitly reschedules the job.
A job can be in, or set itself into, a number of states:
local state = {
NoJob=-1,
WaitingToStart=0, -- If you return this value, 'job' runs again in 'timeout' seconds
InProgress=1,
Error=2,
Aborted=3,
Done=4,
WaitingForCallback=5, -- This means the job is running and you're waiting for return data
Requeue=6,
InProgressPendingData=7,
}
The above states are the first return code. The second one is a (safe) delay parameter which can be associated with a number of the states. This is all part of the normal task action mechanism in Vera (and openLuup.) I've used technique like this for long-running tasks like transferring files from Vera or downloading updates in AltAppStore.
However, even with a zero delay return, as I suggested you try initially, the openLuup scheduler has an anti-race condition mechanism which means that after a number of immediate reschedules, the job will be suspended for a short while to allow other tasks to run. This may be sufficient for Vera to keep up.