It's actually quite common that the reverse situation exists, where there are RISC,VLIW, or other DSP cores on the same SOC as an x86, but primarily as the various controllers and offload engines rather than peers.
Odds are, the ARM SOCs have more ARM or specialty coprocessors, but probably not a stripped-down x86 for offload.
The problem with having the cores as peers would go towards evaluating the different way the systems are structured at a software and hardware level. They handle memory differently, in terms of cache coherence protocols, how they structure virtual memory, and how the different cores can view memory. If they ever operated on the same data or OS structures, serious problems would result.
There are also OS and system software differences that are not likely to take kindly to mixing, and hardware-level differences that require different interfaces to the rest of the SOC and platform.
AMD seems keen on a strategy where they can create a platform that can host both ARM and x86, but have not indicated doing so at the same time. Keeping them separate allows for all the various discrepant interfaces and system requirements to be rebuilt.
That doesn't rule out something like a single slice of silicon hosting an x86 and ARM section, where they operate as physically separate machines with unshared memory spaces, or there's a requirement for a reboot between modes and they never run simultaneously. I dimly recall some kind of 2-in-1 that tried something like this, by having both an ARM and x86 SOC present in the same product, there wasn't enough benefit to the awkward arrangement, and the necessary demand for a dedicated silicon product would need to be much higher than a PCB kludge.
