I too stick to the most explicit version (function($foo)).
It's the same for command line arguments, I have an easier time remembering words (--preserve-permissions for instancem --volume, etc.) than letters if I don't use the interface enough.
So that's why we now have half-assed OOP in Javascript, we have Scala which is basically all programming languages ever, etc. Meanwhile, Go is still fighting a lot of requests to add language features, knowing full well the complexity added to the compiler (and more importantly the cognitive overhead for developers).
Code documentation should be clear and concise, not to be deciphered through the code author's take on the meta meaning of reserved words.
usort($data, fn($l, $r) => $this->foo($l, $r));
usort($data, function($l, $r) use ($this) { return $this->foo($l, $r); });
usort($data, [$this, 'foo']);PHP arrow functions can only contain a single statement and always implicitly return, so that sort of thing is exactly what they're designed for.
Although worth noting with your second example that you haven't needed to capture $this in closures since 5.4, and in fact it is an error to do so now (though I'm not sure when that was introduced).
Anyways: People are capable of writing loooooong expressions (chaining with && can be good to handle errors from multiple operations in one place (till you have to figure out which specific condition broke)) Thus "single expression" isn't neccisarily short ;)
Anyways: Point is "it can be useful, but developers should think, what they are doing" Perl's "there's more than one way to do it" probably goes too far, but being able to focus on the relevant parts and being able to providing the amount of context needed are good things.