The problem here is fundamentally one of performance - PCIe and other devices cannot function efficiently without direct memory access. The only reason FireWire was capable of the speeds it originally was, was because of DMA. USB didn't have DMA (and still doesn't? I think..) and so for shuttling large amounts of uncompressed data into the address space of a consuming application, it was incredibly inefficient to involve the CPU.
PCI-Express and other buses followed a similar route - DMA is vastly superior to every other way of transferring data.
Theoretically an I/O memory management unit with virtualization support could protect your machine, but I don't know if any OSes and hardware combinations actually use that to protect the machine.
I suppose it made sense when Macs and PCs ran single-user OSes on hardware that lacked memory protection. Keeping the default behavior from that day is not wise for, well, last decade or so. (Fresh OSX seems to have changed accordingly, as the tool's page mentions.)
True, this will not stop an e.g. accepted external drive from DMAing - but it will stop a randomly plugged thing from doing so.
Not having this level is worse than Windows' of old tendency to autorun anything called "autorun.inf" on a media - because autorun was still subject to user privileges whereas the PCIe "autorun" is not.
In practice, I don't think this works out too well for really heavy workloads... both NVIDIA SLI and AMD Crossfire require their own interconnects, presumably because of limited bus bandwidth.
Remember the days when you had a separate MPEG-2 decoder card that externally proxied VGA from your graphics card?
Attacks over FireWire or SCSI were part of the threat model that the Palladium team was concerned about.