In my humble opinion, it's generally something to avoid largely for production code because you're generally not tempted to do it except in sporadic functions that perform disparate tasks. I tend to do it in some scrap code used to test things, but find no temptation to do it in production code where I've put some thought in advance as to what each function should do, since then the function will naturally have a very limited scope with respect to its local state.

If I feel tempted to reach for it, I see it as a sign to create new functions instead. Of course you have the benefit of allowing resources to potentially be collected/destroyed earlier, but such is the same case with reducing a variable's scope in general which generally doesn't require reaching for anonymous blocks.

I've never really seen examples of blocks being used like this to reduce scope in a meaningful way in a function which didn't beg the question of why it couldn't be divided further into simpler functions with reduced scopes. It's usually eclectic code that's doing a bunch of loosely related or very unrelated things where we're most tempted to reach for this.

As an example, if you are trying to do this to reuse a variable named `count`, then it suggests you're counting two disparate things. If the variable name is going to be as short as `count`, then it makes sense to me to tie it to the context of the function, which could potentially just be counting one type of thing. Then you can instantly look at the function's name and/or documentation, see `count`, and instantly know what it means in the context of what the function is doing without analyzing all the code. I don't often find a good argument for a function to count two different things reusing the same variable name in ways that make anonymous scopes/blocks so appealing compared to the alternatives.

Of course I do this a lot when I write like a quick unit test that does, indeed, count two disparate things in the main entry point. But it's never the type of code that I'd want to add to the central codebase. I've just never found a good reason to do it in languages like Java (it can be useful with the C preprocessor sometimes, e.g.).