But although this was all about OOP, I think the same argument can be reasonably extended to programming in general.

In this particular instance I don't think it can. The problem with OO in Perl is not so much TIMTOWTDI, but that there aren't enough ways to do it :-)

Basic encapsulation is much harder than it needs to be in Perl. There are not "natural" ways of doing it. Sure you can do it with inside out objects and code refs, or using one of the many different CPAN modules - but it's a lot more complicated than it needs to be.

Compare to Ruby or Perl 6 where there are language constructs that support encapsulating state and hiding implementation naturally and simply.

Ruby and Perl 6 have more ways of doing good OO than Perl 5, not fewer. However since these mechanisms more naturally support what people want to do you end up with clearer code. Which is as it should be.

The problem isn't too much freedom, but lack of features. TIMTOWTDI is only causing problems because different people have invented N different ways of getting over the lack of features and they don't always play nice together.

I suspect that the philosophy behind Perl 6 is not very different from that behind previous versions of Perl:

It isn't. However Perl 6 makes many of the things that were hard in Perl 5 easy by providing more and better tools.