That "for the most part" comment is dangerously misleading.

If you have declared script-level variables with my, then turning on warnings will give you "Cannot stay shared" warnings. Do not ignore this! It will seem to work under light testing. But it will lead to persistent weird errors in production, errors like someone occasionally getting data from someone else's page for no good reason.

What goes wrong is that the first time a given Apache process loads the page it works just fine. The second time you load it, those variables declared with my that are accessed within functions in the script are from the first request, but within the main body of the script are from the second.

If you wish to understand why, read Re (tilly) 9: Why are closures cool? and then realize that Apache::Registry works by putting a function around your entire script, eval's that, and then calls that function for each request. Which creates exactly the configuration of that node. So the my variables are accessed within your script just fine - but in functions in your script you get the first request that that Apache process saw. (And in light testing you can easily miss this.)

If you don't wish to understand why, just remember to turn warnings on, and don't ignore the message that they give. In particular the shared warnings can generally be fixed by declaring the variable in question to be global.

Incidentally the porting link you provide covers this point first because so many people get it wrong and then don't understand the weird bugs that they get. Which is why it is important that anyone telling others how to do it should do likewise, so that we don't get more confused people who only look for the code example, port their code, see that it is faster, and then wonder where the weird bugs that people are complaining about came from. (Note that common mis-advice for how to apply strict.pm is, "Just declare everything with my" - which compounds the problem.)