I agree, and I already proposed a timout feature for Particle.connect() a while back.
@Moors7, the problem with any “secondary” function like waitFor() is that it would need to be executed in order to help, but since Particle.connect() doesn’t return from its potentially “endless” endeavour any subsequent function can’t help before it’s called 
Particle.connect() (and other long-blocking calls) should be made cooperative to allow user code to control them and not “execute and pray” hoping it’ll return in time.
The problem is, when you leave the system thread in charge of the reconnection it often fails to reconnect, but when you want to take control of the connection in the application thread, you will lose the decoupling between (unpredictably blocking) cloud connection and business-logic and hence the prime goal of the application thread will be impaired.
This is what I keep arguing about in this issue