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 anonymous blocks being used like this (not involving conditionals, a `try` block for a transaction, etc) 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.). I haven't really found a really meaningful case for using anonymous scopes/blocks. Every time I've found myself tempted to do this, it's for quick and dirty scrap code and not because it served as an invaluable way to reduce variable scope in ways that genuinely improved the reliablity and maintainability of the software, but as a quick and dirty way for me to avoid having to write more functions that have a greater singularity and clarity of purpose.

This is not to suggest you forcefully create methods either just to reduce scope. That's arguably just as bad or worse, and what I'm suggesting shouldn't call for a need for awkward private "helper" methods any more than a need for anonymous scopes. That's thinking too much about the code as it is now and how to reduce the scope of variables than thinking about how to conceptually solve the problem at the interface level in ways that yield clean, short visibility of local function states naturally. I agree with Bruno that you can hinder code readability by forcefully shoving 3 lines of code into a function, but that's starting with the assumption that you are evolving the functions you create based on your existing implementation, rather than designing the functions without getting tangled up in implementations. If you do it the latter way, I have found little need for anonymous blocks that serve no purpose beyond reducing variable scope within a given method unless you're trying zealously to reduce the scope of a variable by just a few less lines of harmless code where the exotic introduction of these anonymous blocks arguably contributes as much intellectual overhead as they remove. If reducing local variable scopes to the absolute minimum was worthwhile, then there should be a wide acceptance of code like this:

    ImageIO.write(new Robot("borg").createScreenCapture(new Rectangle(Toolkit.getDefaultToolkit().getScreenSize())), "png", new File(Db.getUserId(User.handle()).toString()));

... as that causes the minimum visibility of variables by not even creating them in the first place. I don't want to come off as dogmatic but I actually think the pragmatic solution is to avoid anonymous blocks when possible, and if they seem so absolutely necessary in a production context, then I definitely your design is worth re-examining.