I can offer a partial answer only:
.po are all the same file format: sector contents only, implicitly ordered. The difference is that DOS 3.3 and Pro-DOS use different orderings, so it's fairly common to use
.po as a file extension in order to be explicit about which of those filing systems' orderings the disk image should be interpreted in. What a particular tool assumes for a plain
.dsk isn't really standardised.
.dsk is far and away the most common format in terms of images distributed, and I would be surprised if there were a hardware drive emulator that didn't support them, though a conversion tool might well be necessary since GCR encoding must be applied to the data to convert it back into its on-disk form and drive emulators often lack either the processing or the temporary storage to do so in real-time.
.nib is an awkward mess in terms of describing a disk. It is a list of the bytes that were read back directly from the Disk II hardware when spinning a disk. What that means is that timing is implicit. Real disks use slip bits for synchronisation — specially crafted on-disk bytes with appropriate holes that allow the disk controller to determine the proper windowing of bits from then on — and you are left with no clue as to where those are. So trying to produce something that would read the same as a NIB when handed to real hardware involves searching for sequences that would work with slip bits inserted*. Which usually means applying some rules about the usual layout of a Disk II disk. Which completely defeats the intended purpose of the thing, of being able to image arbitrary disks.
.nibs are rarely supported in drive emulators, if at all, because of the inherent difficulty in doing that reliably. Really the only context they are reliable in is emulators that aren't actually emulating the physical hardware.
.wozs are relatively new, but are very well-formed. They're just a record of the bitstream per track, with advocated behaviour on how properly to generate weak bits (i.e. produce noise if you go too far between signal). The only simplification it applies is that bit timing is assumed consistent across the track.
It is a relatively new format, though it is definitely supported by at least the Big Mess o' Wires FloppyEmu.
(*) the policy I apply in my emulator is to seek an identifiable epilogue sequence, and treat as much of the following as a sync region as looks reasonable. I have no doubt this breaks at least one piece of protected software.