I don't know if blocks of data can for instance be shared by other files so that the data is not TRIM-ed / deleted.
If my understanding is correct, SSD blocks are larger than filesystem blocks, so deleting a single file may not free up entire SSD block. The TRIM cannot be issued in that case. (citation needed)
I'm asking the question because I'm trying to figure out what it takes to securely delete files from an SSD […]
It's not (reliably) possible on per-file basis. SSDs use wear leveling. Their logical addresses aren't fixed to particular locations in flash. In fact it's the opposite, the controller will attempt to distribute writes evenly across the drive, because SSDs wear out on writes and heavy writing to a particular address could kill corresponding block. The implication of this is that you don't know in how many locations copies various versions of a file are written, including locations that may have been decommissioned due to wear.
The only reliable way of erasing an SSD is to reset its self-encryption key (assuming that your drive uses internal encryption). This, however, "erases" entire drive, but without wasting write cycles - the old data is still there, but without the right encryption keys it's just gibberish.
So: is all data always TRIM-ed on file deletion and if so, when?
Not necessarily. For a long time Linux had performance issues with immediate TRIM-ming on deletion, so a periodic TRIM for the whole filesystem once a week or so was used instead.
If you want to be sure deleted data is not readable, use encryption.