To my understanding, there is no difference between a Write and an Erase.
To explain the difference, I need to explain a little bit how SSDs (or in general flash) works. The two relevant sizes here are the interface block size (the smallest unit of data that can be read or written by the user on the interface, usually 512 or 4096 bytes), and the internal erase block size (often dozens or hundreds of kByte or low MByte). To write one interface block of data, the SSD internally looks for an erase block that has free space in it, and then writes the new data there. If that data is overwritten, it does the same thing, writing typically somewhere else. This means that on an SSD, there are typically multiple copies of each interface block stored, but only one is the most recent and actually readable. Obviously, this is space inefficient, so once in a while, the drive's internal software (called the FTL = Flash Translation Layer) performs GC = Garbage Collection: It finds erase blocks that have very little current data, copies the data still needed to other places, and then erases the whole block.
The underlying reason for this complexity is that in flash, individual interface blocks can be written only once after an erase. To rewrite them multiple times, the erase block has to be completely wiped clean first. Typically, the operation that limits endurance is the erase, not so much the write, and even less the read.
Now you can see that the number of erase operations needed per write depend crucially on the workload. If the workload first writes a lot of data to different block addresses (never overwriting anything), afterwards erases everything at once (with a trim operation), and finally starts the cycle again, then the total amount of erase is equal to the total amount of write. On the other extreme, if the workload first completely fills the SSD with data, then overwrites only 10% of it in completely scattered places, then every erase block will contain mostly valid data; to perform GC, on average you need to do 10x as many erase operations.
The D.O.D. secure erase is quite vigorous on the amount of writes it does.
Before that was approved for main frames, we had to destroy $30,000 disk assemblies by sledge hammer when they were leaving a secure military site.
That got to be rather expensive.
Today, in security and privacy conscious places, there are two approaches to securely erase disk drives (both SSD and spinning rust). The first one is to use encryption, and the standard example is called SED = Self Encrypting Drives. Here each disk drive has an encryption key, which is used whenever data is written. To erase the disk, just change its encryption key, and all the data on it becomes gibberish. If you do that, then the end user (say the NSA or Amazon) has to trust the disk manufacturer (Seagate or WD) to implement encryption correctly. For that reason, actually secure facilities (for example the big cloud providers) physically destroy disks (and most other computer hardware) by running it through shredders. I know that for SSDs, there is some specification of the maximum size piece that can come out of a shredder, it is several mm. This is the high-tech version of the sledge hammer of the old days.
Anecdote: At Los Alamos of the old days, the marines were trained in how to shoot disk drives in case of an attack; they even had wire holders attached to the (washing-machine sized) disk drives that one could put a 1911 pistol into, so it aimed at the correct place.
The intent of the above is avoiding SSD for chatty operating systems by moving the TEMP directories to a physical disk.
Absolutely. Although for amateurs, this typically matters little: the total amount of data going to /tmp is very small, and doesn't justify adding a spinning disk. On the other extreme, there exists temporary data (like database transaction logs) that need to be stored with very low latency, and therefore go onto SSDs and other flash storage, even if that damages the SSDs; that's part of the cost of doing business. And today, spinning disks also have write endurance limitations. So the whole idea "disks can be overwritten all the time, SSDs should not be overwritten at all" is an over-simplification.
For most small business and amateur users, none of this makes any difference.
