In my personal opinion, you’re probably still better off with fstrim.timer for a desktop workstation.
It would work after a reboot. Balancing the filesystem is pointless on an SSD anyway, because SSDs maintain their own internal organization, which does not necessarily correspond to how the user thinks the data is stored.
I’ve tried to learn something about this but I’m afraid that I don’t understand the discard=async (especially async)
Could you explain to me the concept (very briefly)?
Balancing came to my mind because I did it after changing duplication types on btrfs but I wasn’t sure if this is relevant it this situation
It’s more or less the same thing as what fstrim.timer does, but with much smaller intervals. fstrim.timer does its thing once a week, whereas the discard=async mount option does it multiple times a day, depending on the amount of writes/rewrites.
No, it’s not really relevant to a change in TRIM frequency.
Yes and no. It would not have any negative consequences with regard to the installed system, but it would still have an impact ─ possibly a small one ─ on the interactivity and performance of a desktop machine, and it would also still run the same risk as with the regular discard mount option that the kernel issues a TRIM request to the hardware whereby the hardware ignores it because there aren’t enough blocks to be TRIMmed yet. Most SSDs will ignore TRIM requests for fewer blocks than what the drive’s firmware requires.