When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are.

The same applies for other languages. Get a task for maintaining random C code, you will have to fix memory handling problems; get a task for maintaining random JavaEJB code and you will invariably see unreasonable extra layers of indirection added; get a task for maintaining random Perl code, and you will have readability problems.

For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used.

"When I've had to read/bugfix/adapt Perl code, most of the time all the bad things people say about Perl were there, that's just the way how the world works, that's how people are."

This might very well be confirmation bias. If code needs fixed, it's unlikely to be high quality to begin with. The similar examples for other languages demonstrate this effect.

Really, all languages have their strengths and weaknesses. In Perl's case, its strengths also happen to be its weaknesses. :)

"For maintainability, you want something that prevents people from tying all sorts of interesting knots whenever standard, idiomatic solutions can be used."

True, but when standard, idiomatic solutions don't exist for the problem you're trying to solve, being able to tie interesting knots is a lot better than being totally out of luck.

One of Perl's underlying philosophies is "Easy things should be easy; hard things should be possible". There are some things that really could and should be easier (FFI being among them: without installing third-party packages, the "recommended" way is to splay open Perl and start fiddling with its C internals, which is absolutely absurd; something like FFI::Platypus really ought to be included by default), but Perl has an "anything is possible" mentality that is invaluable for solving hard problems.