not an expert, but…
Qubes approach is to assume you will not never a perfect system, so, yes, we must assume every system will be hackable (by an adversary with enough motivation and/or resources). We can assume that your regular AppVM is comparable to the distro on which is based on (fedora, debian, etc).
There is BIG difference here: your regular AppVM is based on a template that is not exposed to the internet, so the “system” file changes will not persist across reboots. But an adversary could persist in the home folder (and another 1 or two folders). Of course, if you use a disposableVM, there is no chance of persistence.
All this makes it significantly harder to compromise you AppVM.
Much more important than that: you digital can be put into compartments so that if one can be compromised, the other will not (hopefully). But that is on the hands of the user: discipline is key here.
read the docs (that are great, I think): Documentation | Qubes OS
All this assumes Xen hypervisor is capable of keeping solid compartmentalization: so that can be a point of failure here. Fortunately xen seems to be well audited by lots of people. Qubes team uses a version of xen with less lines of code in order to reduce attack surface. And the track record seems to be good enough.
Of course, if you think it a bit, there is still motives for concern. Intel hardware is full security flaws, and here the track record is embarrassing (for intel architecture). Most of the issues were caused by the need to support legacy features and a drive to improve performance (as we can see now, at the expense of security), or the need to simplify IT management (like the management engine which causes a lot of debate, as it is impossible to remove on modern hardware)
BUT, if your adversary is not the most sophisticated, you should be safe.