My understanding is that the major issue with these WD drives is that they try to hide the fact that they are SMR. For desktop workload or similar, it's relativ

My understanding is that the major issue with these WD drives is that they try to hide the fact that they are SMR. For desktop workload or similar, it's relatively okay, because there's some part of the disk that's CMR (the traditional HDD encoding) and the disk firmware migrated data from there to SMR in the background. As long as writes to the disk accumulate in a way that leaves time for the firmware to run this migration, the writes appear to work similarly to full CMR disks. This is called 'disk managed SMR'. The other, I'd say the correct, way to do this is to have the disk report its SMRness to the operating system. That lets the OS issue TRIM commands to the disk for areas that are not used to store data, which makes the writes quicker, SMR's performance having to do with the fact that it needs to be written in way larger blocks than CMR. For ZFS or RAID rebuilds on drive-managed SMR drives, the CMR area will be filled quickly, as the whole disk is written at once. This means the rebuild will be very slow, and if I got it right, some firmware versions even stop accepting writes when the CMR area is full. So the rebuild situation is where the problems arise - already existing arrays should be fine, especially with SMR disks that do let the OS know about them being SMR.