mjhjmtu

When running the command hdparm -I /dev/sda the following output is generated.

ATA device, with non-removable media
 Model Number: WDC WD10JPVX-75JC3T0 
 Serial Number: WX51A9324970
 Firmware Revision: 01.01A01
 Transport: Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
 Supported: 9 8 7 6 5 
 Likely used: 9
Configuration:
 Logical max current
 cylinders 16383 16383
 heads 16 16
 sectors/track 63 63
 --
 CHS current addressable sectors: 16514064
 LBA user addressable sectors: 268435455
 LBA48 user addressable sectors: 1953525168
 Logical Sector size: 512 bytes
 Physical Sector size: 4096 bytes
 Logical Sector-0 offset: 0 bytes
 device size with M = 1024*1024: 953869 MBytes
 device size with M = 1000*1000: 1000204 MBytes (1000 GB)
 cache/buffer size = 8192 KBytes
 **Nominal Media Rotation Rate: 5400**

Of interest is the description and value Nominal Media Rotation Rate: 5400. This indicates that the hard drive is mechanical and not flash.

There is support for ATA secure erase as suggested by the output albeit I would have not anticipated a secure erase taking as long as 198 mins.

Security: 
 Master password revision code = 65534
 supported
 not enabled
 not locked
 not frozen
 not expired: security count
 supported: enhanced erase
 198min for SECURITY ERASE UNIT. 198min for ENHANCED SECURITY ERASE UNIT.

Given that the device is not a solid state drive, should a secure ATA erase still be performed?

If no, why? If yes, why?

Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?

Given that the device is not a solid state drive, should a secure ATA erase still be performed?

If you want to erase the data, you can use ATA Secure Erase. It is not meant only for solid state drives and works fine on spinning rust. It takes a lot longer than on SSDs because hard drives are less likely to support SED, which allows instant erasure by destroying an encryption key.

Whether or not you use the firmware's secure erasure or erase the block device is something that is up to you. Both options come with advantages and disadvantages. For example, ATA Secure Erase is designed to erase areas of the drive that may not be touched by writing to the block device, such as damaged sectors and the HPA (Host Protected Area). On the other hand, any erasure implemented in firmware may be broken or implemented incorrectly, as you have no ability to easily tell how it is performing erasure. If you have time, you can perform both methods to get the best of both.

Would shred --verbose --random-source=/dev/urandom -n1 /dev/sda support the same or a similar outcome i.e. irrecoverable data including defective or deallocated sectors?

No, that would not erase damaged sectors, nor would it erase areas of the disk like the HPA. Note that the command you gave is functionally equivalent to cat /dev/urandom > /dev/sda. You can, however, use smartmontools to determine how many damaged sectors your drive is reporting. If the value is zero, then every accessible sector can be wiped just by writing to the block device.

If you want to overwrite the block device, you can do so with dd:

dd if=/dev/urandom of=/dev/sda bs=256k conv=fsync

This will write random data to the block device, and will sync the changes as soon as it has completed. On older Linux kernels, the random driver is very slow, in which case you should use other sources of randomness, for example creating an encrypted device with cryptsetup and writing zeros to it.

In the future, there is a technique you should utilize to ensure you are not put into this position again. You should use full disk encryption with something like LUKS, which keeps the randomly-generated master password on the drive, encrypted with a user password you specify. Simply overwriting the encrypted master password is sufficient to render all other data on the drive completely irrecoverable. This works for hard drives where there is no wear leveling in place. On solid state drives, this will not work.