Understand the ST library code is not heavily tested/validated, so you'd need to evaluate it further and perform your own test, and test across a variety of cards and examples. Some USB sticks skip the crystal, so the timing might be outside specifications. Used by thousands of customers you're bound to get some that don't work or are otherwise of poor quality.
In my experience (magnetic/optical storage background) these flash drives tend to be pretty robust, they manage the wear, and also handle the error-correction and block sparing. Basically a NAND memory with an MCU to manage them. The biggest cause of data loss is likely to be file system level corruption due to bad software, caching or power interruption. Make sure the file system content cleanly flushes prior to card removal. Things like FatFs finalize the file system data at f_close, or f_sync events.
For transient logging I don't bother with verification. If the data is critical, you might want to do so at the erase block size (128KB, or what it reports), doing sector level read/write will be very slow. For linear writes perhaps keep a running hash that you can check via a subsequent read-back.
For SDCard / eMMC with FatFS system implementation I tend to fill the media with pseudo-range test patterns that don't align to sector/cluster boundaries, and don't repeat in simplistic fashion. I've done this on STM32 out to 400GB or so. The FatFs middleware shipped by ST is OLD (2017), don't use it for critical applications, it has known flaws.
