This prevents the EC2 blueprint from hammering the AWS API when SSH or WinRM start returning immediately.
We observe this scenario occurring frequently, but we just don't have access to the internal Amazon implementation to find out why their networking behaves like this (does the connection terminate while EC2 is assigning IPs, does the connection terminate because the box temporarily brings up a firewall that REJECTs instead of DROPs, etc.) The actual causes for why the connection might be refused instead of waiting for the timeout are numerable and impossible to know (and may vary for different people).
This bug fix is required because in the event the connections are refused, we don't want to hammer the EC2 API in a fast-running loop and consume all of the API credits. When all of the API credits / limits have been exhausted for the time period, AWS blocks API access to all applications on the account, and thus when this scenario occurs, Phabricator essentially ends up DoS'ing any other applications using the AWS API.