To the extent that oddities get in the way of getting our collective jobs done, yes. And very few of us actually have jobs where golf or obfu is part of the requirement, which is where some of these oddities get (ab)used.

When I'm coding, I'm not looking for a "fun" language. I'm looking for a practical language. One that does not get in the way of me finishing my current task to get on to the next task. That doesn't mean I can't enjoy the task of coding, it just means that fighting oddities is not the enjoyable part of the task: completing the task faster and more reliably than any of my teammates is the enjoyable part of the task (for me). Having the flexibility to think in the problem space rather than the solution space is enjoyable (for me). Being able to do things the way that I think they need to be done, not necessarily the way the language designer(s) thought they should be done, is enjoyable (for me). Fighting oddities is not.

It's not even as if Perl is the only language with oddities. C has a bunch, too, many (if not most) of which Writing Solid Code tell you to avoid.

Having the flexibility to think in the problem space rather than the solution space is enjoyable

Yes, and this is why some oddities may even help. The fact that ' ' as first argument to split is slightly different than / / is certainly an oddity. But useful. The fact that // has a specific meaning, but not if it's used as a first argument to split, is also an oddity. But useful.

Not every oddity is evil.