I generally agree with your point, but when those coders are learning a bunch of other things at the same time (like why it's nicer to pass back a reference than an array or hash), it can be one more thing on their stack. I have some influence on the standards, so I try to pick and choose which Perl idioms I want to push for and which I let go.

So, given your example, I guess we've decided that we'll go ahead and put the padding on the corners. At first, they'll run into the table, later they'll go around but hit the padded corners. Eventually, they'll navigate the office (or the code) nearly flawlessly, and even then the padding doesn't hurt them. There are a few drawbacks, but not many. And the additional advantage is we avoid some ambiguity.

I think the cool thing is that Perl makes this sort of thing available, even if it is optional. Your padding example is apt because this sort of thing does pad the learning process and 'takes the edges off' the learning curve. These things can be invaluable when you have an office of people re-learning (from a mainframe environment or a non-coding background) or tackling other similar learning curves.