Really, the benign-vs-malicious question is an oversimplification. But thats what we have data for, and what most people focus on.

The reality is there is a big gray area between the two classes. Some cases are really hard to determine, and would be something that would lead to errors in production. Some examples:

What if it is of malicious intent, but the author messed it up and so it doesn't do anything. Is it still malware?

What if it's a program used for encryption for security, but used by malware to create ransomware? Is it malicious now?

What if its a benign program, but a bug causes it to destroy files. Is it malicious?

Some programs are maybe not malicious, but just annoying (like browser toolbar installers). What do we call it? Some systems have a "Potentially Unwanted Software" category for these guys.

Ultimately, it's not easy. Thankfully most binaries are fairly cut-and-dry in terms of which side of the fence do they belong. The hope is that with enough labeled data, we can do a good job for the majority of cases. We don't expect it to ever be perfect. Hitting the hard to distinguish samples is definitely something dig into in the future.

It's almost like an inversion of the usual image classification problems, where you want to identify the broad strokes of the image while reducing sensitivity to the value of individual pixels. Instead, here, you want to ignore the overall shape of the program (which is likely to be benign) and focus on tiny details to pick up sneaky hostile behaviour.

You'd probably have a weight of some sort so if the program wants to modify N files, it gets 0.23N 'suspicious-points'. To get how many files the code wants to modify, you have standard symbolic execution without actually performing the syscalls/WINAPI. Same with checking if the deletion is in the main code path vs behind some event trigger. There's no silver bullets but you can certainly factor 'normal' behavior into your analysis.

sandbox and analyze the end result (file actions, system-level actions) of running the software - the actual results of use don't lie. until they do, where you have context-sensitive viruses that detect VM's and are generally designed to not trigger when analyzed.

Right, and that kind of malware is going to have a lot more code than just a negation.

yeah but how does it determine the results are not what the user intended?

Malware that just does that is not going to be very useful to a blackhat, who generally has some purpose in mind besides just wanton destruction. They are going to want to control the computer, ransom the data, or spread to other machines.

My point wasn't that file deletion is the goal, my point was a single bit could change the entire meaning.