Those are often-abused features of Perl. I've seen crazy things done with map when much simpler stuff would have worked. I would definitely encourage people to think twice before choosing them, but I wouldn't ban them. Sometimes they are the best thing to use.

A lot of this comes down to knowing what the shared level of knowledge you can expect from your team is. When I worked at eToys, we wanted to use mod_perl and OO code extensively for a new version of our system. To that end, I taught a brief class on mod_perl fundamentals, and we hired merlyn and TheDamian to help our team with OO and some of the tricky but useful Perl idioms. We gave everyone a copy of the Effective Perl and OO Perl books. That gave us a higher baseline than most Perl development groups, and freed us to use some trickier stuff.

Even so, any time I used something a bit unusual like a hash slice, I would document it carefully. Sure, you can look it up, but you have to spot it in the first place and you have to have some idea of what you're looking up to know where to find it.

Your English analogy is actually pretty good because I think it makes my point. When writing English for fun or for an audience of serious readers, you can use some wild and obtuse stuff. People have often "hacked" English for artistic purposes and created great things. However, if you were writing for a newspaper you would be expected to use a subset of English that supports the business goal of the newspaper, i.e. being clear and easy to understand for the average reader. Newspapers have extensive style guides on how you should use English in their papers. Perl shops tend to be less prescriptive about it and assume that you will exercise some common sense. Since most places have bug fixes and enhancements as major goals for their projects, writing code that the available pool of programmers can maintain is an implicit rule.