You're likely seeing a limitation of PATA: two drives share the same bus (channel), and only one can be actively using it at a time. Busy processing a command with the host waiting for the result counts as using it. I've seen some drives that immediately return after
hdparm --security-erase and process the command "offline", others
hdparm does not return until the command is done. I suspect the former drives would allow master & slave to to both be doing it at once.
Note this did sort of improve over the many years PATA was in use; and mostly the improvements went to where it matters: read and write commands. And dd can do both drives even if they're ancient because its not one write command, it's many, many write commands. (On truly ancient drives, it's actually taking turns — write some sectors to one drive, write some sectors to the other; newer modes allow the drives to receive the write command, buffer it, and process it "off-line" freeing the bus, that way both drives can be writing at the same time).
(BTW: This is also why when you had PATA drives in RAID arrays, both mirrors needed to be on different buses. Either the master or slave failing would often take out the bus.)
If you have multiple PATA channels (or buses, or whatever you call them), each should be able to handle a drive doing a security erase, concurrently. I've successfully used USB PATA interfaces to invoke secure erase (and dd as well, I personally do both); and of course it's trivial and fairly cheap to add more USB devices. At least for the security erase, which doesn't take USB bandwidth.
SATA, of course, is point-to-point, there isn't a shared bus with multiple drives. So this issue doesn't exist.