It took 30 secs all together to crash the tasks. Not worth the hassle to cancel them. We will catch the failures at post processing.
If they crash immediately, let the tasks crash.
If they take more than 2 minutes to crash, Please report.

Maybe its not worth it for us to run your project then.

Sorry. The erroring tasks take only few seconds to finish, right? So very little cpu is wasted. It is not easy to gather wu ids to cancel. Even the failure is a result. Maybe we will grant some credit for the failed tasks if that is what you want.

We identified the reason why they fail so now it is OK to let the errored tasks crash since they use very little cpu.

I cancelled tasks with 7 and 8 at start as soon as the problem was found. Then I received a list of tasks to resurrect, but it seems I made a mistake, or the list was wrong and resurrected tasks that still crash. We will let this batch (12) finish and then figure out which rows are missing and re-issue good tasks.
The batch 10 is finished and most likely we will have more tasks to send after it is analysed by miss Makarova.

Several seconds for the hundreds/thousands of tasks among all the users. If BOINC mgr decides to interrupt another task to run these for those few seconds much more time could be lost than what was spent on your tasks.

"max # of error/total/success tasks 3, 10, 6" Error limit of 3 yet these were sent out 4-5 times. I would have suggested to just lower the allowed error rate so they would not be sent out again. 1 setting but I'm not sure that even works here.

Sure it may still be beta but no user wants a reply to just deal with it when it could be fixed.

First, Boinc manager does not interrupt tasks unless it has checkpointed recently.
Second, it was misunderstanding to resume some of the tasks. First Natalia asked cancel 7, then sent new version of the batch rows, and then asked to cancel 7 and 8 anyway. But I received the messages out of order: first cancel 7, then 8 and then new version of batch. That was a big waste of my time and also your computer time. And for this similar reason I set it up the "sending scheduler request, requested by project" timer, to abort unneeded tasks on clients quickly.
The tasks were set more than 3 times, because boinc server software is stupid (sometimes), and probably was not made to handle tasks that were aborted and then un-aborted.
Reduce max number of error results is double edged, yes, your computers will not waste five seconds of time, but instead I would have to spend hour manually scanning the database and resurrect tasks that were marked as failed, because someone uncleanly reset their computer or whatever.
Yes, it could have been fixed sooner. I repeat, errors are OK. We see the errors use the information from the errors to fix them.
I bet this discussion would not be so long if the task was marked as success and credit granted for it.