Security is a process. Many things that help security can become language features. You've mentioned memory management. You go on to mention some of the benefits of capability designs. But even if you have all of those, you don't necessarily have any security.

In this case the fundamental problem was addressed in part 5 of Dan Berstein's description of what he did to make qmail secure. Don't parse!

The Perl bug that the webmin discussion uncovered was due to how Perl parses printf strings. SQL injection attacks are due to Perl programmers unsafely constructing SQL for a database to parse. In short any interface where one side sends formatted text for the other side to parse and do something with is a complex interface that is very vulnerable to bugs if the one side allows slightly wrong data across that interface. And bugs properly exploited lead to security holes.

Capability systems do not change this fundamental fact. What they are better at is making it more difficult to escalate bugs into serious security violations. That is not completely true. It is possible to take a capability system and build an insecure piece of software. If you want, you have the tools to do it right. But having good tools does not guarantee success. As an example I'll point out that one can build a POSIX subsystem out of a capability-based system, use that to port standard Unix software, and then despite your capability based roots you're back to the normal Unix situation. Admittedly only for the data that is in the POSIX subsystem, but if that is the data that you care about, that is a cold comfort.

So one message that you could walk away from this with is that any language that really cares about security should avoid parsing. However if you're going to interact with existing systems, you're quickly going to find yourself having to interact with existing interfaces that are text-based. For instance databases, email, HTTP, and flatfiles. So the natural APIs to build will involve parsing. And that isn't a question of the language that you're using - it is about the legacy systems that you're interacting with.

Now you can build wrappers around those APIs to avoid parsing. People do - for instance they use Class::DBI instead of writing SQL. (A major issue with this kind of thing is that you can then only access features that the API has exposed. If you need more sophistication, then you need to go to the underlying API...) People can also find options to make the parsing interface simpler - for instance using placeholders instead of dynamically constructing SQL. However at some point you have to accept that there is a programmer responsibility to understand the issue and do things right.

Perl offers tools, eg taint mode, to make it easier to do things right. Perl could do more. But no matter what, some of the responsibility must belong to the programmer.