The basic USB protocol does not allow for direct peripheral mastering of DMA (unlike IEEE 1394 or PCIe for example). So, barring a protocol exploit in the USB host controller, which is certainly a theoretical possibility given the enormous size of the specification, fencing off the USB host controller using the IOMMU is just an additional layer of protection, rather than a necessary boundary like it is for a PCIe or 1394 device which has access to memory natively.
A USB-C/USB3 physical port makes things a bit more complicated, as it also could be attached to a controller supporting Thunderbolt, which is PCIe.
The unsafe part of plugging in a USB device is probably at the OS level rather than the protocol level - in my opinion you're much more likely to be owned by something like connecting a device with a buggy or compromised driver, mounting a filesystem containing an FS exploit, or reading a file containing an application exploit than by a USB-level protocol exploit.
Right, that's why I said "but no, you're not safe because crappy USB drivers can probably be exploited if they're expecting the USB device to be playing nice."
Finding a USB protocol level exploit would be like finding an exploitable bug in how a NIC does scatter/gather of packets. Like, notings impossible, but damn.
You still shouldn't stick random unknown USB devices into your computer though.
A USB-C/USB3 physical port makes things a bit more complicated, as it also could be attached to a controller supporting Thunderbolt, which is PCIe.
The unsafe part of plugging in a USB device is probably at the OS level rather than the protocol level - in my opinion you're much more likely to be owned by something like connecting a device with a buggy or compromised driver, mounting a filesystem containing an FS exploit, or reading a file containing an application exploit than by a USB-level protocol exploit.