++greengaroo, your list contains good advice. I would like to add some of my own. But, first, I do have a few quibbles:

6) Raise a flag, when creating if-elsif blocks without an else. Double-check that you don’t need an else. In doubts put one that would provide an error message.

This should stated more generally:

Be mindful of corner cases. Remember Murphy’s Law! For example, when creating if-elsif blocks without a closing else block, ...

8) Don’t pass big structures directly as an argument to a subroutine or method, use references instead. You never know how big your structure could become and it would use a lot of memory.

This is true in C, but not in Perl, where subroutine arguments are passed by reference, not by value. See perlsub:

The array @_ is a local array, but its elements are aliases for the actual scalar parameters. In particular, if an element $_[0] is updated, the corresponding argument is updated...

Of course, once the argument has been passed in, it is common practice to assign it to a local variable, and this assignment does make a copy. So point 8) is still good advice, but needs to be re-stated (and generalized). For example:

Don’t make an unnecessary copy of a large structure when a reference will serve instead.

14) follow these [debugging] steps:

This tip should definitely include a reference to Basic debugging checklist by toolic.

Now to my proposed additions:

16) Observe the Principle of Least Privilege. Don’t use a global variable where a lexical variable will do. Don’t declare your variables until they are needed. Use accessor methods on objects. Use blocks to minimize the scope of local, no strict 'refs', etc.

17) Avoid premature optimization. Remember,

We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. — Donald Knuth

In fact, the Wikipedia article on program optimization says it all:

A better approach is therefore to design first, code from the design and then profile/benchmark the resulting code to see which parts should be optimized. A simple and elegant design is often easier to optimize at this stage, and profiling may reveal unexpected performance problems that would not have been addressed by premature optimization.

18) Study Chapter 21, “Common Practices,” of the Camel Book.

Hope that helps,