workeronthewalls
QubesOS is running virtual machines. If one virtual machine gets compromised, the attacker is still confined within that virtual machine, and cannot access data stored in other virtual machines, and cannot compromise other virtual machines. Unless they also are able to find a vulnerability in the CPU microcode, the Xen hypervisor running all virtual machines, or the minimal communication framework between virtual machines and dom0 implemented by Qubes to support clipboard sharing, sending files to other virtual machines, and seamless mode for displaying windows.
GrapheneOS, and in fact all Androids are similar. GrapheneOS is instead running each app inside an app sandbox. If the app gets compromised, the attacker is still confined within that app sandbox, and cannot access your files (unless the app has been granted permissions to read all files), or listen to your microphone (unless the app has microphone permission granted) and so on and on. But if the attacker is also able to find a vulnerability in the CPU microcode, kernel, the app sandbox, system Android processes or similar, they might similarly break out and get access to everything, like if an attacker breaks out of a virtual machine.
The difference is that app sandboxing is a much weaker protection than virtual machines. The attack surface is much bigger, meaning the risk of an attacker finding a sandbox escape vulnerability is way higher than a virtual machine escape vulnerability. There seem to be a few such sandbox escape vulnerabilities fixed each month in AOSP and GrapheneOS, while QubesOS only have some each year.
To answer your question if separate user profiles matter, no not really. The app sandbox is per running app. But apps running in separate user profiles are forbidden from communicating with each other using intents and similar standard IPC mechanism, which might mean a compromised app cannot talk to apps in other user profiles without breaking out of the app sandbox too. But maybe you see that as a privacy advantage rather than security one.