Under bait files, there's no problem
With bait shares, there's 2 issues with excluded files
#1 - The memory requirements to implement a watch on every file is immense. IIRC during my testing, inotifywait did not sent an event if a linked file was deleted (ie: encrypted / re-written, and the source removed) Because of that an attack cannot be detected unless every single file is watched or the directory is simply watched for any changes.
#2 - The response time for inotifywait decreases with every additional file being watched.
(As an aside, I just tried it and simply creating a .ds_store file will trigger an attack because of the change in the folder)
I have no clue under what circumstances Finder creates those files, but I believe I have seen in the forums here instructions on how to stop finder from creating them in the first place.
I really don't know what to say beyond stop your script from deleting them from bait shares, or stop finder from creating them in the first place. But no matter what, always keep in mind that this plugin is the last emergency line of defense (for the files on the server only), and to always make the necessary precautions on all your other networked devices to prevent any ransomware attack from happening in the first place. The attack won't originate from the server, but from another networked device, and its highly probable that all the files on that particular device will be trashed no matter what.