The "it's the capacitors" answer has already been given, but that's not the whole story. Let's look into that a little deeper.
Most devices run from house-voltage AC (110V or 220V AC), at 50Hz or so, through a power adapter, to low-voltage DC (5V or 12V DC).
AC current is current which cycles back and forth, from positive to negative... which means passing through zero. So, for a fraction of a second, 100 times a second, there's no voltage provided to your device.
Obviously, then, your device must be capable of handling a /very brief/ power interruption, or it wouldn't stay on for more than a hundredth of a second. The way this is done is first by stepping the voltage down to reasonable levels in a transformer (a couple of coils around a core: the big heavy bit in most power supplies). That changes you from 110V AC to, say, 20V AC.
Next step is to convert it from AC to a lumpy kind of DC: a "bridge rectifier" (four diodes arranged so that whether the voltage is flowing one way or the other on the input, it flows only one way on the output). So instead of waves up and down from +10 to -10, you get a series of lumps, from 0 to +10.
Then that voltage needs "smoothing": that's where the capacitors come in, and we get rid of the zero-voltage dips. Each voltage "lump" charges the capacitors up; each dip discharges it. The bigger the capacitor, the more current it can store as charge from that "lump", and the slower the discharge time is. Which means, the smoother the output is.
But there's always some fluctuation, so there's often a "voltage regulator" as the last step, a chip which takes anything from, say, 20V to 3V, and outputs a reliable 5V or so.
Then all the components take that 5v, and convert it into 5v and 0v to mean 1 and 0... except, they don't. They convert it to "voltages above or below a couple of volts" to mean 1 or 0: so there's lots of leeway there.
The processor (and most devices like routers have one) is basically a black box which reads in a command, performs the actions the command says, goes to the next command in the sequence, and repeats. And it does this constantly, from the moment it's turned on.
The processor uses some of the charge from those voltages to store things in its internal memory, in a "volatile" form, which discharges fairly quickly, so needs constant power to "remember".
One of those things it stores is the "program counter" - that is, which command it last read in, so it knows how to do the "go to the next command in the sequence" bit above.
When you turn a processor on for the first time, it tries to read in the program counter, and because the memory has completely discharged, the program counter contains the value zero. That means it's booting up... so it reads in the command from address zero, which is the boot code. [nb: big simplification here! In truth, other things also need to hit zero for a reboot.]
So, when you power cycle, you need to wait long enough for:
- the smoothing capacitors to discharge enough that...
- the voltage regulator's ability to regulate the voltages up is insufficient to keep the voltage above...
- the processor's level needed to keep the program counter stored, for long enough that...
- the processor's program counter storage discharges.
If you don't do that, then it's possible that only part of it discharged: that the program counter stores a random value. The same is true of any other volatile memory on the system, too, so even if the CPU has not discharged at all, the data stored in memory at the address the program pointer points at, may have degraded.
Either way, you then have the processor not knowing it needs to run the boot code, and instead trying to run some random code somewhere. That's not good and probably won't un-crash your router.
One second is probably enough. Five seconds is almost certain to be enough. Counting to ten is almost certain to be enough time for five seconds to have passed. Therefore, unplug, count to ten, plug back in.
This is why, when you get a brief power brown-out and the lights go dim for a moment, sometimes your router works fine (nothing discharged, it carried on as it was); sometimes it crashes (memory got corrupted); sometimes it reboots (power was out long enough that the processor fully discharged the program counter).
If we're separating the device from the heavy parts of the PSU (that is, our router has a wall-wart power supply, and we're unplugging from the back of the router, rather than from the wall) then we can be faster, since we've separated the capacitors from the device. But we still need to give the volatile memory time to discharge. Odds are, the time it takes us to unplug and plug back in again is sufficient. But... are those extra nine seconds so valuable? Probably not. Count to five, maybe.
So, without dismantling the device and plotting the current drop and memory discharge time across each component, the summary is:
NO. The minimum safe reboot time is not precisely quantifiable. It's not constant even per-device, or even per-reboot for the same device.
[Note: all the above is a dramatic simplification of reality, but it's at least somewhat better than "it's the capacitors!"]
[Edit: from having worked tech support, I know that if you tell someone to unplug and then plug it in again, they'll quite often just not do it, but tell you they did. It seems that people are reluctant to just do an action and then undo it: they will shortcut the action to its logical conclusion, where nothing has changed. Equally, if you think a cable has been unplugged and ask them to check, they will often confirm to you that it is plugged in perfectly without ever getting out of their seat to check.
But when unplugging is just a step to doing something else (waiting ten seconds), then it's OK. So, if you tell them to unplug, wait ten seconds, and replug, they are FAR more likely to do it. So that ten seconds has a psychological use, too!
The very best, though, is to ask them to pull the cable out, blow on it to make sure there's no dust breaking the contacts and introducing noise, and then push it back in. I have NEVER known someone not to unplug when given this instruction. The blowing, obviously, does nothing other than ensure they first unplugged the cable and then waited a moment before replugging. Asking them to follow this procedure is also far, FAR more likely to succeed if you think the cable has just been unplugged. It obviously fixes 100% of those situations, but only a fraction of them will ever admit "when I went to do that, I found it was unplugged..."]