Yep, and that's why a lot of old code has things like retry loops when a server starts in case binding the socket fails, or if a configured network interface/directory doesn't exist (instead of failing fast), etc. So much cruft could be cleaned up if we embraced this new world where we finally have reliable dependencies.
Sure your web server "started" 5 seconds after boot, in that a PID now exists for it, but that doesn't mean it will serve a web request if dhcp hasn't finished yet. `/etc/init.d/nginx status` tells lies on those old systems.
Call me crazy but I think it's much better for software to recover from (some) asynchronous/transient conditions by itself (at least if it's not a trivially stateless service). I've had to go great lengths to implement transparent redundant networking for software which doesn't know how to reconnect a TCP socket and instead just hangs for 5 minutes.
> retry loops when a server starts in case binding the socket fails, or if a configured network interface/directory doesn't exist
I think the issue is systemd takes the stance of the "safe" route first, which is not really necessary for most personal machines and not the greatest when people are using mostly flash. But a 90s timeout makes sense if you are loading a 20TB hdd (I've even seen longer load times on much smaller drives)