Othere systems which use roll-up write techniques to optimise write performance see this sort of effect. NetApp OnTap will do it if you run to high space utilisation levels as the available free space gets fragmented and it is more difficult to do efficient writes as there are few "clean" areas to do the most efficient writes. The worst access patterns are those with lots of small, random updates (typical of a database) - if the workload is largely sequential writes then it is much less of an issue. However, given that the random read speed of these tjhings is a lot better than real disks, decent algorithms which avoid defragmentation could be implemented a lot more efficiently than with real disks.

Isn't this what a wearlevel system is all about? Mapping logical blocks to random physical blocks so that all cells get an equal amount of write/erase cycles.

What could contribute to the slowdown is that for some reason the dirty cells aren't erased again quickly, so at some point a write operation has to wait for an erase cycle to free up a cell.

Good idea, but unfortunately they saw honking levels of perfomance degradation in read operations, so it isn't anything about writes having to wait for an erase to occur.

Conventional fragmentation makes no odds to an SSD anyway, it doesn't matter which cells you read in what order, the access time's the same as there's no physical geometry or moving head to take into account. This leaves Intel's "packing" strategy as the likely culprit and the authors here make a compelling argument for this.

That solution will result in the slowdown, if it were present at all previously, at the point of 80% of the 75% sized partition (even sooner than not doing it).

Until we see some numbers and methodology we can't really have a clue what's going on. If the reviewer of that other article has been hesitant about pubishing serious stats, I'd say it raises questions about the validity of his review. Until then I feel it should be - innocent until proven guiltly