How would that work? The problem here is that chroot needs to run using a different CPU instruction set. qemu-user is exactly the right answer here.
According to e.g. https://wiki.gentoo.org/wiki/Systemd-nspawn "no hardware emulation is taking place and unlike QEMU and Virtualbox non-native CPU instruction sets are not directly supported".
systemd-nspawn is still using binfmt which is how Linux tries to read ELF files, and what you really want when executing other architectures is to teach binfmt about qemu.
nspawn doesn't do anything additional here, but might be easier for most new sysadmins (sorry... "devops/platform/cloud engineers").
cd into an OS image built for arm on your x86 dev machine, and type:
`systemd-nspawn -D .`
and it just works. At least it's never failed for me. I believe it pulls in some kind of binfmt/qemu shim to get these binaries working. Probably qemu under the hood, but this is about as plug-n-play as it gets.
According to e.g. https://wiki.gentoo.org/wiki/Systemd-nspawn "no hardware emulation is taking place and unlike QEMU and Virtualbox non-native CPU instruction sets are not directly supported".