IMO, though, there are a couple minor instances of wording (not fact) that might mislead your target reader. So, herewith, some 'picky' comments:

First para: "Before using strictures, your program just didn't work right. Now it blows up!" While NOT technically correct, I'd be inclined to surround the phrase "just blows up" it with quotes which some read (in this context) as signifying "ironic effect." Given that not everyone shares that view, perhaps typography could help: italicizing might highlight the irony.

In the section, "Purpose of Strictures", you say (2nd para, 2nd sentence) "Also, the error message tells you where...." To my eye and ear, that sounds like an afterthought, diminishing it's importance. Maybe a <ul <li list with the two items thus (equally, to the eye) bulleted for attention. Esp. for the noobie, "where" is probably at least as important as "what" an error is... and by the time you mention "working backward from there" in the section on debugging, the noob may have gone off to try another iteration of the offending code.

Under the "Strict Errors" subhead, would you want to add (perhaps parenthetically, after "You may not understand the SOME_ERROR_TEXT but you should start looking for a problem in FILE at LINE." a very brief note that an error message sometimes places the error one or more lines after the actual mistake?

On the other hand, I wouldn't reorganize: your "chainguard" simile works very well and re-orging the following para would destroy the nice, natural transition you've created.

Under "Strict Vars" it seems to me that you use the "Reason" subhead in a slightly different way that elsewhere. Rather than being augmented explanation of the prior point, it is, in this case, the introduction of a new one -- that strict helps catch typos (admittedly, only if the intended Var in question has been declared). This may be a tough one to enhance while staying concise.

In Subs, I question restricting the advice to fix a bareword subcall to suggesting that the budding programming add an "&" -- re-ordering, subs first and predeclaring are at least equally valid.

And, lastly, in line 5 of your (well-done) code, you say "# comment out to avoid errors." I would greatly prefer (well, you did mark this "RFC") "# comment out if you don't want Perl to help you find your errors."