|P is for Practical|
I'd write that as:
If your construct was necessary, I'd use the the block form of map and I'd make explicit the $_ argument to uc. The implicit arg to uc distracts me most. These are just personal preferences.
The short and quick answer to your question is be merciful. For me, that you saw the need to ask predetermines the response.
Were I sitting in your place considering simplifying and expanding code, I would be considering the size, complexity and stability of my_sub[not sic]. If my_sub is stable, which is to say well defined, well implemented and well tested, then the issue is less significant; noone is apt to need to read the function body--an ideal toward which to strive. If the function is large, readability may be helped by the shorter version. If the function is complex, making it easy to read becomes more beneficial to a maintainer.
When I run into functions with which I am unfamiliar, I try to look them up; Perl's builtins are easy to look up so I'd likely just keep the map.
The Perl constructs which I think are more worth avoiding for readability's sake are those based on punctuation. I don't mean the variables found in perlvar, rather things like a dereferencing a hashref slice; I don't see that as so complex just difficult for the unacquainted to look up.
In reply to Re: Should I leave behind beautiful code or readable code?