delay() is implemented as a "tight" loop that keeps the flow trapped for x milliseconds performing a Particle.process() call (if required by system and threading mode) once every 1000ms accumulated delay time.
Additionally v0.7.0 will get rid of this "need" (for Electron devices this is already implemented that way in 0.6.2)
SYSTEM_THREAD(ENABLED) already changes some rules about delays.
Some cloud tasks will be performed on the "free running" system thread (e.g. servicing Particle.variable() requests) while others need to run on the application thread (e.g. Particle.function() callbacks or Particle.subscribe() handler calls) and hence require a call of Particle.process() (the quicker the more responsive the device will be).
If you want to do other jobs while waiting (but not only then), you definetly should adopt a completely non-blocking coding scheme - multi threading and interrupt driven approaches should "only" be employed when this does not suffice.