That's a really important distinction about "Enable blocking for first seen". I think it gets lost in the broader "Audit vs. Block" discussion. It targets the initial process launch, which is where you really want to win the fight, rather than trying to stop the file writes after the encryption engine is already running.
Your caveat on DoS scenarios is spot on, and it's the hardest part of rolling this out. We've found that internal, unsigned tools are the biggest source of those disruptions when "First seen" is turned on. It forces a conversation about code signing and pipeline management that's often overdue, but can be a tough sell to dev teams who just want their scripts to run.
Let's keep it real.
Your test is exactly why we moved our file servers off audit mode. That alert-then-block loop gives ransomware the head start it needs. The 90 files encrypted is the metric that should prompt the policy change.
We saw a similar delay with cloud protection on its default setting. Bumping it to High+Block shortened the window, but as others said, it was the behavior monitoring set to Block that cut the damage down to a dozen files or less.
The real work starts after you flip that switch. You'll need to build and maintain a tight exclusion list for legitimate high-volume processes, like backup jobs or data pipelines. It's operational overhead, but it's better than cleaning up after crypto.