I suppose this depends largely on what you mean by "tracking progress". Are you wishing to track personal progress? Or, is it the progress of colleagues, subordinates, students, potential employees/contractors, etc. (or some combination)?

The idea of "progress" is highly personal, and as such it is often a mistake to try to put numbers on things like skill and experience. Well, to a point, anyhow.

From the point of view of a hiring manager (in a past life), my thoughts on some of your criteria:

• Posts/XP on Perlmonks is largely irrelevant: I'm sure there are fantastic Perl programmers who rarely post, and may hardly log in to read (or may not have bothered with an account). Maybe they simply don't think Perlmonks is a good idea, or a host of other factors that have little or no relevance to skill.
• CPAN modules used/written. Well, what about someone who solved many problems that are unique to a field, and CPAN wasn't as helpful -- further, they may not have been allowed by management to publish the modules they write to CPAN.
• Salary increase is an odd measure, because there are other perks that geeky people are likely to value. I've taken pay cuts to work for managers with a clue, or to take work with seasonal companies (summers off!).
• I would rephrase the bit about other languages: someone might be a minor Perl diety and not know other languages at all. It's unlikely, but nothing about deciding to focus energy on being an excellent Perl programmer would necessarily be a bad thing. There is value in knowing something about other languages, but I wouldn't weight that knowledge very heavily.
• Number of projects completed is worthless without an understanding of the complexity of those projects. And by complexity, I mean problem-complexity. One of the projects I'm most proud of took me two years -- the majority of which was analysis and experimentation to pin down the problem -- and ended up being "small" in terms of code size; still, it's a very elegant solution that has now been in production without modification for three years, and saves that organization hundreds of thousands of dollars a year.
• Ability to pay more bills is a nice perk to being a good programmer, but it's not a way to measure progress. See my comments about salary increases.
• Riding the corporate ladder is often inversely proportionate to programming skill. Corporate advancement is about understanding office politics more than being a skilled developer. In fact, as a manager, I'd rather just reward my skilled developers with more pay, more vacation, and other perks than "promote" them within the corporation -- a lot of fantastic developers don't want to manage, because it means less time for what they are good at and enjoy (writing code).

If I were to try to score a potential employee, the criteria would be something like:

1. real-world experience (time)
2. familiarity with solving diverse types of problems
3. familiarity with a number of Perl resources (knows about Perlmonks, various USENET groups, CPAN, etc.)
4. ability to spot common "gotchas" in code (e.g. spot where a use of '||' instead of 'or' might cause problems)
5. knowledge of best practices for writing new code (e.g. use of strict, warnings, POD)
6. knowledge of when Perl is not the correct choice, and ideas about alternatives
7. understanding of different development models (e.g. RUP, XP), and methods (e.g. procedural, OO, functional)
8. willingness to find/use existing modules to solve problems (perhaps tested by development of a simple solution for a made-up, but realistic, problem that is 90% solved on CPAN)
9. an awareness of what (s)he does not know

Even these would be rather hard to assign numerical values to without a large degree of subjectivity...