F2FS experiences

[z4v4l]

this belief:

That why log-structured filesystems (like F2FS) or copy-on-write filesystems (BTRFS, ZFS, BCacheFS) are better for flash:
They *never* modify/overwrite inplace (which will invariably trigger a read-modify-write). They *always exclusively* append writes by definition (which can be write-only by allocating fresh free erased blocks from the wear levelling pool).

contradicts to your own previous paragraph:

Trying to overwrite and change in-place any content small than that size will always trigger a read-modify-write cycle. (with the small details that the erase block that get "read" and "erased", and that the erase block that get actually "written with the modified version", might actually be two different block in order to rotate which blocks get erased and spread the wear).

and it's not a "small detail", it's essential and it's exactly what makes all these F2FS and alikes unnecessary for anything except bare NAND - because internal controller does manage the internal flash storage and only it can do wear leveling for real. at best, that "flash friendly" FS does nothing bad to the card. FS has no clue about internal "geometry" of the storage and thus cannot do anything helpful with respect of wear leveling in particular, it writes into logical LBA space and all its "super duper log based/cow" features apply to it. and it has nothing in common with the internals of flash.