If I remember correctly, there's an interesting historical reason for this: a lot of the original functionality that we'd today consider "part of the OS" was actually in ROM on hardware in really old Macs. Mouse functionality, basic windowing, etc. This meant that to get A/UX running you first had to bootstrap into a light version of Mac OS and then boot into A/UX.

It is sort of the same for DOS. When you start digging around in the source you realize it is only really half an operating system and a surprising amount is done in the BIOS.

Not really (I wrote the mouse/display drivers and kernel event queue driver for A/UX 1.x) - A/UX has it's own kernel ADB (and mouse/kbd on top of that) and display drivers, it will happily boot from hard drive, and throw up a non-mac terminal on a Mac display card without executing anything from the Mac ROMs.

The later MacOS running on A/UX ran in a single A/UX (system V) process

The Toolbox ROMs, right? I can see the utility of using that (I mean, beyond that you might need to use it to boot), but why couldn't A/UX call those APIs itself? I can easily see where bootstrapping through Mac OS would be easier, but I can't immediately see why it would be particularly necessary.

Yeah, that was similar to Amiga and the Kickstart concept, initially on floppy, then as a separate ROM module. Going from AmigaOS 1.3 to 2.0 with the applicable Kickstart ROM gave you a whole new UI layer.