Please install and use systemd's fstrim.timer

"Fsrim timer can't be enabled by default for all devices. Even when emmc reports itself as trim-capable, running fstrim still results in a data corruption on some devices. So it should be enabled only after testing per device model."

Can you please provide a source link or some own analysis for this bold statement, which contrasts to what most Linux distributions do.
Until then IMO there is no reason to believe that the eMMCs in devices supported by SailfishOS lie about their capabilities.

The remaining two paragraphs are definitely FUD:

• Yes, on freshly TRIMmed FLASH one might (if discard zeros data) be able to detect which blocks are in use.
  So what, if you do not regard yourself as a potential victim of targeted attacks (e.g. by a secret service) and have everything encrypted (the filesystem reveals the same info much better)?
  Plus if you do believe that "they are after you", a regular Smartphone with SailfishOS (e.g., reflashed from Android) is definitely the wrong choice, anyway.
• There is nothing "so problematic" about "direct discard", some distributions use it for FAT filesystems (e.g. SailfishOS).
  It just may be slow when utilising old FLASH-controllers with deficient firmwares.
• All this is nicely described and thoroughly discussed in the links the OP provides: Reading often helps to prevent oneself from spreading FUD.

There are devices for which TRIM/queued TRIM is blacklisted, look in the libata-core in kernel source. Even though those are SSDs, emmcs may have the same problem, and there is too many of them to make blacklists. Sometimes problems are caused by faulty firmware, and considering the quality of firmware for mobile devices, there even more possibility that there are devices that corrupt data when you TRIM them.

I am not arguing that periodic trim shouldn't be enabled at all! But if there is a probability that it would corrupt data on some devices, maybe it's better to enable it per device model, after testing, to avoid that?

Well, the security argument is ridiculous in my opinion too, but it might be important for paranoid people. There is no point in encrypting a personal device at all IMHO.

SailfishOS 3.2.1 on XA2 Plus, none of the mounts have discard option. And it will be counterproductive if continuous trim will cause frequent freezes instead of speeding up flash memory io.

Basically agreed, except for that the eMMC firmwares are of concern, not device firmwares. There are actually less available eMMCs than SSD models, as eMMCs do not have such diversified supply chains. Why do you suspect their firmwares to be of inferior quality, albeit being developed and manufactured in a more coherent manner?

But these are exactly the documented (per each and every of the links in the OP) considerations:
"For how long do we continue to negatively affect speedandlifetime of the vast may of well behaving eMMCs and SD cards, in order to avoid mishaps with the few, old FLASH controllers, which incorrectly report their capabilitiesandhave a faulty Trim implementationandare not blacklisted?"

IMO, Jolla might check per fstrim -av on their officially supported devices and then deploy and enable fstrim.timer for all devices or a subset of these, depending on the outcome.
Already positively checked on Jolla 1s, Xperia X, XA2 and 10 and I never saw any reference to eMMCs misbehaving WRT Trim (in contrast to some SSDs > 5 years ago). Do you have one or is this just speculating?

P.S.: Well, this (enabling systemd's fstrim.timer) is not about "direct discards", anyways.
BTW, thanks for hinting that Jolla stopped mounting (v|ex)FAT with it. Just checked, Jolla stopped using the mount option "discard" when they switched from their sd-utils to udisks2 for mounting SD cards and USB-attached media in SFOS 2.2.0 (i.e., in 2018).