So the obvious (although contrived) example, would be a CMS where the username is prefixed to the filename (rather than put in a subdirectory).
Another example would be somebody just wanting to hog a lot of in-kernel CPU time, and causing conflicts with their own filename, even though they're rate-limited by higher-level schemes (eg. server-level rate-limits).
Creating a conflict with a lock file created in the same directory is probably another example.
As a previous poster alluded, crc32c is good for detecting random corruption, not for hash tables or malicious corruption.
The CPU implementation of crc32c argument is also deeply flawed - extra tree walks are not worth the few cycles saved, as tree walks are vastly more expensive.
Remember that hash tables are only O(1) in a "perfect hash" scenario, so the hash table performance approaches what you'd expect from O(n) as the hash gets worse.