Ok, I found a good explaination on Wikipedia (https://en.wikipedia.org/wiki/Trim_(computing)):
The original version of the TRIM command has been defined as a non-queued command by the T13 subcommittee,
and consequently can incur massive execution penalty if used
carelessly, e.g., if sent after each filesystem delete command. The
non-queued nature of the command requires the driver to first wait for
all outstanding commands to be finished, issue the TRIM command, then
resume normal commands. TRIM can take a lot of time to complete,
depending on the firmware in the SSD, and may even trigger a garbage collection cycle.
This penalty can be minimized in solutions that periodically do a
batched TRIM, rather than trimming upon every file deletion, by
scheduling such batch jobs for times when system utilization is minimal.
This TRIM shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued TRIM Command.
This boils down to: synchronous TRIM is bad for performance if you run it on every delete (via “discard”). Hence the move to a cron job that does a full trim on a weekly basis.
The Samsung 850 Pro does support trim, as seen in your test, but only synchronous due to the blacklist still in effect.
So if you do not use “discard” in fstab and just rely on the fstrim cron job, you should be fine.
And yes, it looks like I’m going to get the 850 Pro now after all.