The bit that makes it read backwards is that the delay runs after the start, not before it.
In the XAPI code the VM is booted and then the call just sits there for start-delay seconds before returning, so the one you set it on is already up. What waits is whatever was going to happen next.
Which is why it belongs to vApps rather than to autostart. An appliance groups VMs, and order decides which group goes first. The blocking start is what creates the gap between them (https://docs.xcp-ng.org/vms/vm-lifecycle#vapps). Autostart on its own has no ordering at all, so you are not missing something obvious there.
What I cannot tell you yet is whether an appliance gets started on a host reboot at all, or only when you run appliance-start yourself. I would rather try that on a test host than guess, so let me come back to you on it. Meanwhile there is an open request for your exact case, a VM that should wait for another VM: https://github.com/vatesfr/xen-orchestra/issues/8433.
Your NAS and seedbox example would be worth adding to it.
