I don't think preferences should determine your decision. It's a matter of judgement based on experience - a personal issue, certainly - but not preference.

Ideally, you never throw your code away. Agile methodologies such as frequent refactoring and testing help you avoid this: refactoring makes your code less messy; testing checks that your code meets your needs where your needs are specified within the tests.

Your code should allow the integration of new features, whether from CPAN or not. You need to take good care of it as it evolves. I like the pragmatic programmers' programming as gardening metaphor.

Taking responsibility for others' badly maintained, disorganised code needs some thought. As does dealing with your own badly written code. No matter how hard you try, it's easy to write rubbish. Sometimes you write bad code deliberately: you evaluate risk, experiment and learn.

So, when should you rewrite code? It depends on what you want to do. If the code won't evolve significantly, maybe you can throw a few tests round it and hope nobody asks you to modify it significantly. This happens less often than you might hope. Alternatively, you may find you can refactor much of it, writing tests as you break the code up into meaningful routines. If you find it hard to decide initially, why not set aside some time to experiment with refactoring? You may give up on this, but you will understand the code better.

A couple of months ago I chose to rewrite some code and only discovered its complexity as I got more involved with it. In the end, we gave up after spending too much effort completely overhauling the existing work. This reminded me of the importance of frequently, honestly evaluating work, understanding risk and recognising the positive aspects of failure.