F2FS experiences

[DrYak]

contradicts to your own previous paragraph:

No, it's two different things.
- The append only nature of log-structured (F2FS, UDF, etc.) and copy-on-write filesystems (BTRFS, ZFS, etc.) means that there is less inplace writing (compared to appending, and therefore less overall erase. You litterally avoid performing erases (wears the flash) and avoid read-modify-write cycles (bad performance). You get less erases in total for the same amount of operations. (At the cost of complexity of FS and/or RAM usage).
- That the flash management will put an erase-block back into the pool after erase, and will perform the writing into a different erase-block pulled from the pool, will spread the wear. You get the same number of erases (not less), you just avoid the erases constantly happening on the exact same erase block and thus wearing a single point prematurely. You also neet to read-mody-and-write: no matter if you write elsewhere, you get the performance penalty.

A. is about reduction of erases and reduction of RMW cycles.
B. is about avoiding the erases always happening in the same point.

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.

You're confusing modern flash filesystems (F2FS, UDF) with the "alikes" (JFFS, JFFS2, YAFFS, UBIFS, etc).
- The point of modern filesystems is the reduce the number of erases and in-place overwrites (and thus RMW cycles). (point A above). They can work on flash that has an advanced controller, and in the case of F2FS was designed with such a controller in mind to begin with. (F2FS only reduces the writes. It doesn't care about the actual wearlevelling, that is left to the controller. It just makes the job of the controller easier by making less often necessary to erase blocks or perform R-M-W). UDF specifically can reduce the inplace overwrites to absolute zero and work in "append-only" mode on medium that is write-only (like CD-R DVD-+R, or that can only be erased as a whole like CD-RW), that's why it became a popular successor to ISO9660 for optical media.
Thes modern filesystem can even work on things which aren't even flash to begin with, but which don't like in place overwrite much. (the prime example being spinning rust HDD that use a "shingle" type of magnetic track arrangement)

- The old-school filesystem are designed with bare flash in mind and handle the wear-levelling themselves. Not only do they try reducing erases and in-place modifications, they also take care to make sure that the erases and writes happen at different places in flash and are evenly spear accross the medium (and in case of UBIFS, there's an entirely separate layer - UBI - dedicated to the task). If R-M-W is necessary, the filesystem itself makes sure that the write part is performed at a different position in the raw flash. It basically perform the point B above, but entierly in software. This is a concern that is entirely absent in F2FS.

if you only manipulate a couple of files, a few KiB each:
- the old-school flash filesystems will make sure that they have cycled through the whole raw flash before reusing a block.
- BTRFS will basically allocate only 2 data-chunks max and happily append to each in turn while releasing the other (I am over simplifying, and skipping the metadata chunks, etc.) It will be the role of the flash controller to make sure each time a chunk is released and then reallocated, a different groups of erase-blocks is picked up from the pool.

at best, that "flash friendly" FS does nothing bad to the card.

At *worst*.
At *best* a "flash friendly" FS makes sure that you run a lot less erases and/or R-M-Ws cycles than performing the same operation on FAT32/exFAT.

FS has no clue about internal "geometry" of the storage

True for F2FS, UDF, BTRFS, ZFS, BCacheFS, etc.
Nope for the older: JFFS, JFFS2 and YAFFS2 assume a "raw" geometry (UBIFS is a bit different. It assume UBI, and it's UBI's job to handle the raw flash. There's a separation of concerns).

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.

For the absolutely specifics of the wear leveling: indeed it doesn't influence it directly. But that's not its job. F2FS doesn't care directly about the low-level details of wear-leveling. The job of F2FS is to make data organised in such a way that you seldom need to erase a block and seldom need to modify data inplace.
That has the indirect effect that the internal controller will need less often to perform read-modify-write cycles.

In short:
- old-school flash filesystem are all about making sure that the writes explicitely different address in LBA space. Make sure every single LBA has been used at least once before recycling them.
- modern filesystem are all about making sure that erase less, mostly by avoiding repeated writes to an LBA in the middle of two other already-written to LBAs, but preferably to an LBA that is in a region that got issued a TRIM before. If all this only happens in the same 4GiB chunks of a 128GiB eMMC: don't care.