You are conflating the linear layout of your code with the flow of your program, which is not necessarily linear. If you can specify what should happen at scope exit, you don't need to specify that at the end of the scope, especially if the scope can be left through various exit points, like die for example. And it's even less a matter of where such things are specified and more a matter of that they're specified and executed at all, for all exit conditions. And hence, it's easier and IMO even clearer to specify what should happen at cleanup time (whenever that is) in the same place where the resource is acquired.

I'm deliberately conflating linear layout of code with the flow of the program, because that's what makes it easier to read. Exit points other than } are typically easier to notice, and can conceptually link "special thing happens here that I should watch for" with that point in a programmer's head.

I want a warning at the } if you have created an object that is going to do something special at that point and nothing has been done to make it visible. Call your destructor explicitly as a reminder, unless doing so would be even worse (i.e. you built a dozen of these objects in the same scope), in which case, put a single-line comment at the } and another at the line that turns off the warnings.

But as I said before, this is a stylistic thing, and I imagine it's not really worth getting into a big scuffle over it.

Exit points other than } are typically easier to notice, can conceptually link "special thing happens here that I should watch for" with that point in a programmer's head.

No. How many exit points are in this code:

sub foo {
  my $resourceHandle = acquire_locked_resource();
  my $dbh = get_database_handle;
  my $count = get_current_users($dbh);
  my $elapsed = get_elapsed_time();

  my $users_per_second = $count/$elapsed;

  $resourceHandle->output("$users_per_second users/s");

  $resourceHandle->release;
};
[download]