This is a little bit intended. When "primary" device with dhcp fails, there is something wrong with the network and we should skip the interface and move to the next one. Only non-fatal failure of dhcp is the case where there is working ipv6 dhcp on that network. 
And also changing this functionality would require huge changes in the code. So for both of these reasons this is WONTFIX for me.

I disagree with both of your reasons, separately.

Not having a DHCP server is not something "wrong with the network". Just off the top of my head, a plausible use case here is a laptop. eth0 configured for DHCP for when the laptop is plugged in at home, eth0:1 configured with a static IP for when the laptop is plugged in at work (where there isn't a DHCP server).

Also, this particular misbehavior can be fixed simply by commenting out the "exit" in question, which results in eth0 being up and [partially] unconfigured, and eth0:1 being up and configured. If a different behavior is desired then that might "require huge changes in the code", but *A* solution exists with a trivial change.

Hi Clarence,

I agree with opinion in Comment #3 that if DHCP does not work on the network and we expect it be there, interface and it's aliases should be skipped. This comes from the idea that network initscript is intended to be used for static configuration. 

WRT. trivial code changes, it might be needed not only to solve how to deal with partially configured interface, but with static routing as well.

Even if we agree that the interface should be skipped when DHCP is missing, I don't see where the leap to the aliases being skipped comes from.

If a primary interface could have a static IP while an alias had DHCP, then this would make more sense, because then DHCP could fail without breaking anything. But DCHP/static pairs are forced to come in that order, so skipping the static alias because the dynamic address failed makes no sense to me.