A component being on the same die as the CPU doesn't mean that it isn't isolated. The SoC components in Snapdragon chips have IOMMU isolation. In modern computers, including smartphones, there are many components inside and outside SoC with memory access. A component being on the SoC is orthogonal to whether it has direct memory access. Direct memory access is supposed to be contained properly by an IOMMU, and that's the case for most of the components in the devices targeted by GrapheneOS. It's one of many kinds of hardware / firmware security properties that's going to play a substantial role in researching and choosing devices as targets.

Research is currently ongoing into choosing at least one decent low-end device with the least security compromises. There's no way to avoid losing some of the fancier hardware security features like the HSM because they aren't offered. The expectation is still that all the basic hardware / firmware security features are intact, which includes a decent IOMMU implementation, verified boot / attestation, at least a TEE-based hardware keystore (if they don't have a nicer HSM implementation like the high-end targets), etc. Many of the baseline security properties are tied to the SoC, including the IOMMU implementation for SoC components. Device vendors and the peripheral hardware vendors (like Broadcom for Wi-Fi) end up responsible for properly setting up IOMMU containment for peripherals, and that's often where the ball is completely dropped. There are often problems tied to where there are boundaries between organizations because there's often a lack of responsibility taken for these things. SoC security is unavoidably something that the SoC companies are responsible for handling, but issues like properly containing the Wi-Fi SoC can end up relegated to being treated as someone else's problem by every company involved.

May have been an issue in the past. Daniel claims that modern Pixel devices (among others) use IOMMU to control which memory segments the baseband device can access, and if implemented correctly it should only allow what is necessary for device->driver communication.

I do think more research is needed.