vtsyhqoty
In an air-gapped system, such as a phone or computer that is put in true airplane mode (modem actually powered off completely), and with no other connectivity of any kind, the only real threat of compromise is while the system is initially installed, and every time an external device such as a USB thumb drive is connected. The latter might exploit vulnerabilities in the driver or applications. If the system was definitely clean when initially installed, and you never connect any external device, it is basically impossible for the system to be compromised. Theoretically, the QR code parser might have vulnerabilities, but I don't think this is very common.
Sometimes, it is not really practical to have fully air-gapped systems, so one might want to try simulating air-gapped systems as far as possible. This is typically done using virtual machines. The idea is that the host OS is air-gapped, as in, does not have any network or USB controllers assigned to it at all. They are instead assigned to a network and USB providing virtual machine using IOMMU. This way, you can create virtual machines that are completely offline, ie, does not have any virtual network cards or virtual USB controllers assigned to it. And other virtual machines can have a virtual network card connected to the network providing virtual machine, and similar for USB devices. QubesOS is an operating system for computers that implements this. But this is not perfect, because there might be a vulnerability in the virtual machine hypervisor, ie, software that runs in host OS to provide the virtual machines, that any of the virtual machines with network access can exploit to gain full control of the whole device, including all offline virtual machines. There might also be vulnerabilities in the microcode running on the CPU itself that allows leaking information from other virtual machines even without a host OS compromise. Vulnerabilities in both of these classes are found in practice, probably one or two every year. But an attacker need to already have compromised one of your network connected virtual machines to even be able to exploit these second vulnerabilities. It is a good simulation of an air-gapped system, especially if you promptly install security updates, but it is not perfect.
GrapheneOS does not implement any way to simulate an air-gapped system. Separate user profiles is not this. GrapheneOS does not have any separate host OS, it is just a single operating system. The kernel runs the network drivers, and vulnerabilities are found every now and then, and exploiting them would give the attacker access to the whole system, including all user profiles. Unlike the virtual machine case, only a single exploit is needed to fully compromise the system. Although apps are sandboxed, the attack surface for breaking out of the sandbox and getting full access to the whole device is far larger than in the virtual machine case. An attacker getting full access in a single user profile mean the attacker gets full access in all user profiles. Not even toggling network connectivity on and off before unlocking the offline profile will help, as the system might already be compromised at that point.
Vulnerabilities that allows an attacker to fully compromise up-to-date Android based system is found basically every month. While GrapheneOS implements many exploit protections that would stop some of these vulnerabilities from being exploitable on GrapheneOS, the attack surface remains large.
In the end you have to think about what risk you are willing to take. Where would you be comfortable storing the private keys to your crypto wallet? What is the risk of an attacker getting access to them, and what are the consequences of getting your money stolen?