... I think I get why. Getting an A3000 to boot from a different controller is no easy task. So I'm guessing the SCSI chip has to send a "go" signal to the ROM chips, otherwise the processor can't access the ROMs to begin working.
Straight and simple: No.
The A3000 scsi is in no sense any different in its boot process compared to any other host adapter, let it be SCSI or IDE. Any such host adapter creates a boot node in the operating system indicating that it is willing to offer bootstrap services. In case of the scsi.device, it is done in the kickstart ROM itself, in case of third-party host adapters, this code comes from the boot ROMs of the adapter and is initialized through the expansion.library.
So in terms of the boot process, the A3000 is not any different from any other machine. If the Apollo host adapter does not boot iself within an A3000, there is something quirky about it I do not know. It probably does not have a boot rom (as its manufactures went lazy) and probably relies on the bootstrap code of the scsi.device to take over its own adapter - or something similarly hacky.
One way or another: This is not a problem of the A3000, the kickstart or the scsi.device in the system. It is a problem with an improperly implemented firmware at the Apollo side.
As far as the Os 3.9 scsi.device is concerned: There are at least two known bugs in the 3.9 code which prevert booting under some circumstances, and even trash memory or crash in others. But that is in no relation to the above problem.