#2 ignores one of the function's return values without making that fact explicit to a casual viewer at the time the function is called. We may have a difference of style here, but to me, that's wrong. If you're going to discard, use undef.

#3 indicates a position where a filehandle was used for an open and never used again, not even to check return value on a close. For the trivial example you posted, where no data is ever written, this is fine, and I can make it explicit (and avoid the warning) by simply closing the file before the braces end. It adds all of a dozen characters, and leaves the warnings valid for any time I had opened multiple files, and then accidentally used one of the file descriptors twice in a row instead of using the one I intended.

#6 isn't required to make an inside-out object; it's a shortcut for making an anonymous scalar instead of an anonymous hash, and I've never had it explained to my satisfaction why it is substantially better than an anonymous hash, which by removing a named variable at least makes it clear that the variable isn't intended to actually hold anything.

On to the other class of examples, I just tested that #1 in fact does use $foo++, and warnings::unused handles it properly:

#!/usr/bin/perl

use warnings;
use warnings::unused;
use strict;

my $foo = 42;
my $bar = 43;
exit(eval q[$foo++]);
[download]

Unused variable my $bar at ./warntest.pl line 8.
[download]

#4: I misunderstood your example, my apologies, but now that I think I see what you're getting at, I'm not sure why putting your locks in your constructor (and by the way, although again this is a matter of style, I would not personally use constructor methods named in such a way that they can be easily mistaken for procedures) is substantially better than instantiating a new object containing the resources you want unlocked and then explicitly locking the object until it passes out of scope. The latter seems clearer, and I would not mind a warning for that reason alone.

#5: Again, I misunderstood what was being done... but I'd argue that this is exactly why I want a warning on code that looks like that. You've hidden functionality inside a destructor-only event that is going to trigger many lines of code away from when you prepped it. I want a warning if someone does that. You can lose the warning by explicitly undef'ing the object before it goes out of scope, which makes it very clear that an object going out of scope is about to do something significant other than going away.

I guess the short version of this is, I don't see any situation where using a declare-once-and-forget variable is ever clearer or substantially more efficient than an alternative, so I don't see any of these situations as warranting exceptions from warnings, even if they are in common use.