There's an option 4: you are running out of RAM and macOS is doing a lot of swapping.

These SSDs can probably write on the order of 3000MB/s = 0.003TB/s, so you could end up with 155 TB total writes after just 155/0.003/3600 = 14 hours of RAM heavy workload.

It would have to be a legitimately RAM heavy workload though... running out of RAM due to leaving applications open (or browser tabs open), might result in swapping out those to disk until they are used again. But the level of swapping required to generate this much write usage would essentially be using the disk as RAM, as in the running program doesn't have enough RAM, either due to needing more than physically available or due to buggy memory management.

Right, I was thinking of things like large simulations where you need to keep a large dataset in RAM and update every datapoint at every iteration.

Or maybe multiple VMs running simultaneously doing CI jobs could also do it.

I don't think simple memory errors like leaks would cause it, since that would just end up filling the disk once, but wouldn't go through writes quite as fast.

The symmetry between reads and writes precludes a lot of options (like logging gone mad). I'm not even sure most SWAP ends up read back in...

That reminds me, when SSDs first came out we'd have to set noatime on nix stuff including macs, to prevents the OS from writing file access times every time a file is read, otherwise it would cause significant write amplification. Modern SSD controllers are clever enough to make this unnecessary these days, but it could be something similar... either with the SSD controllers themselves or a file system behavior spaced just right in time to turn 1 byte into 4096 bytes of effective NAND writes - That's only 24GB of requested writes turning into 100TB in the worst case.