I'm sure that there are aspects of this that I haven't appreciate, but from the Minix paper on IOMMU, I really cannot see how this specific feature provides the protection.
IOMMU is not a new concept. It's there to allow bus attached devices controlled access to the real memory address space of the machine for DMA type transfers. I first came across a feature to implement this was in the Unibus I/O address mapping system (Unibus map) in 16 bit PDP11 computers with 18 and 22 bit addressing extension back in the 1970s. The basic concept is to allow an I/O adapter controlled access to part of the main system memory in a way that does not allow access to bits outside of the control.
In that implementation, the OS set up the Unibus map for the I/O (Most Unibus devices were only 16 bit capable, so they needed a translation mechanism to be able to write outside of the first 64K of memory), and the DMA then occurs (it was more simplistic then, because there were no overlapped I/O operations, so differed I/O operations requiring the state of the UNIBUSMAP to be saved through context switches were not an issue). The protection offered was actually a side effect of the mechanism. This gave protection from rogue Unibus DMA transfers, but left control in the hands of the OS.
This is what is described in the IOMMU Minux paper, nothing else.
In order to implement something like this to provide protection from from the OS itself, it is necessary to have the checking code in a higher protection ring than the OS. This is normally reserved for type 1 hypervisors, and the capabilities for this have existed for many years. It would have been perfectly possible to add this type of function to the hypervisor or to a service VM running parallel to the OS, so the OS makes a hypervisor call to check the validity of, well, pretty much anything at all including checking the cryptographic signature of new code. In this way, running Device Guard as a service VM controlled by the hypervisor rather than the OS means that it cannot be tampered with by anything in the OS. This is what I think Device Guard actually is, supported by the statement "with its own minimal instance of Windows". Make the hypervisor and Device Guard also signed by UEFI, and it's pretty difficult to tamper with the system as a whole.
Of course, VM segregation requires an MMU and an appropriate security protection ring, and it is possible that this is why there is some confusion about which part of the MMU is providing the protection, but IMHO, it's not the IO function of the MMU described by the Minix paper, more the general features of a VM capable Memory Management Unit. It's probably the Extended Page Tables feature that is actually required for Intel processors.
This is the type of thing that IBM have been doing in their mainframe operating systems running under VM (the mainframe hypervisor product) or PRISM for many years. As I understand it, the RACF security system runs in a separate VM to provide additional security.