I noticed some jargon terms (SOPW, RTFM, etc) weren't spelled out the first time they were used - might be a good idea to do so.
Re: compilation. I think we should include a reason (beyond "we think you are being lazy if you don't"). I can think of several reasons we could offer:
Sometimes just making the code compile solves the problems on its own (compiler = rubber ducky?).
If your code doesn't compile, we may get so distracted by the compilation problems that we miss your real problem.
We are helping from a distance. We can't check your system to see if what we offer will work for your specific environment. Only you can do that work, and to do so, you need to have compiling code. (BTW it is ok to ask for help if you can't figure out why something won't compile. But let that be your question then and save the "my script won't do X" question for later.)
The best way to learn to program is "code a little, run a little". That's hard to do if your code won't compile. Learning is what Perl Monks is about.
One thing I liked about the old version was that the author went through the archives and pulled out posts that illustrated both do's and dont's. Maybe we could add some specific examples to illustrate your points?
To handle the "This looks a little long *bing*" issue - use a pyramid organization. Make sure the above the fold portion very briefly covers the main points, and is energetic and maybe even funny. Then in an intro section elaborate. Then if you need to, add additional sections going into detail about each bullet point in the intro.