Full logging of deletes isn't always necessary and can even be highly undesirable. Although TRUNCATE has the desired performance and effect on the transaction log, it can't be used with a where clause. Nor can it be used when foreign keys exist.
People are using various techniques as workarounds:
1. Delete in batches with transaction log backups to limit transaction log bloat.
2. Save the small amount of data to be kept into a temporary table. Drop the foreign keys. Truncate the table. Load the data in the temporary table. Restore the foreign keys. Drop the temporary table.
It's a lot of trouble. So what if the minimally logged delete fails and there's no way to roll it back? I don't care. I want the data gone forever. If the delete fails, I'll just reissue it. I don't need logging or recovery for that.
Testing ETL is one use case. Iterative testing of ETL sometimes requires bulk deletion. Try the ETL, oops it didn't work properly, delete the data, change the ETL and try again. But if a bulk delete takes hours to complete or stops the server because the transaction log runs out of space, it makes everything painful.