"Always write your code as if the next maintainer will be a homicidal maniac who knows where you live."

That saying is not bunk at all. A completely unreadable source is of no use to anyone, regardless how optimized it is. What does it do? Do you know? How will you find an error if there is one? How do you know what is an error or not?

The foremost issue is writing legible code. The fact that you are writing Perl alone, as opposed to C or assembly, means you cannot be extraordinarily concerned with performance to begin with. So if you chose Perl over C, why was that? Now take the next logical conclusion and you'll see that code legibility being more important than optimization logically follows.

Makeshifts last the longest.

I agree with the importance of writing clear code. But this isn't the point that I took issue with.

Your logic is still flawed:

completely unreadable source is of no use to anyone,

Users use code that is "completely unreadable" to them all the time. Code with lost source is sometimes used and may be considered "completely unreadable". If that was all that was available it would be used often.

If every programmer died today, do you seriously think that software would be unused tomorrow?

What does it do?

Don't you have to execute it before it does something?

Do you know?

You could execute it and find out.

How will you find an error if there is one?

You would execute it. If you can not execute it, it has no function.

How do you know what is an error or not?

If it is not executable it does nothing. Is that an error? If it executes and performs the functions desired then it is correct.

The foremost issue is writing legible code.

The foremost issue is writing code that does something, that executes, that performs a desired function. Legibility is a adjunct toward that end.

You are like a person who says air isn't that important, you are taking it for granted.

Your position is ridiculous. If you must cling to it, I hope it serves you well.

You could execute it and find out.

Assume that the program produces no messages whatsoever. You run it without parameters, it says nothing. You pass a file as parameter, it says nothing. You list the directory, there's no new file, the one passed hasn't changed. Hmm, that probably wasn't it.

Or suppose you have a library with absolutely no documentation.

Tell me how you would go about finding out what the code does at this point.

Of course the fact that code is executable by a computer is not quite incidental, but the essence of that saying is that you should write your code as if it were. In fact, you are already thinking by these lines, even if you don't realize it.

Makeshifts last the longest.