No, your sleep does not block the FTP command. Let's sidetrack into kernel process management for a bit:

Since their invention CPU cores can only execute one process at a time. This meant that a single process waiting for user input could block the whole system. So someone came up with the idea of time slices. Each process is allowed execution for a certain time. After that time it returns control to the kernel. All was good until some processes didn't return control on purpose.
Most modern kernels use preempting instead. Again, each process is allocated execution time. After that time the OS kernel is woken via a timer interrupt (or sooner if the process gives it's rights back because it's waiting for something), the first process is sent into a sleep mode and another is given CPU time. The first process will continue when it's its turn.

Now back to your case: you're starting the FTP process and send it into the background. It gets its time-slices just like any other process, but it's not executing the whole time. Sometimes other processes are executed, so ftp is marked as 'sleeping' or, better said, waiting for its turn again. If you only have one CPU core and get the current list with ps, all processes except for ps will (most likely) be marked as 'sleeping', since ps is currently using its allocated time to gather the stats.

My suggestion for your problem would be:

1. ping the host in question (maybe mark those pingable accordingly and skip the others)
2. test if the FTP port is open. You can either use netcat (eg: netcat -z $host 21 and check $?) or parse the output of nmap)
3. create a small checkfile on the FTP server, and fetch that first. For example, start the FTP command for that in the background. If it's still running after 5 seconds, consider the host dead.
4. if all (necessary) checks are good, continue with the large transfer