That goes completely against my experience (15+ years with Perl). The only "boilerplate" required by strict is to declare variables which typically consists of three extra characters - that is not onerous.

Best practice is to only declare variables in the scope they are used and to initialize them when they are declared. In your sample code that amounts to 28 extra characters counting the "use strict;" statements. That is about a 2% overhead. 2% does not equate to "much faster" in my book.

"running prototype" != "working prototype". A simple typo in a variable name that strict would have alerted you to can easily soak up tens of minutes of debugging time or introduce subtle calculation or logic errors that may go unnoticed. Just one case like that detected by strictures will more than outweigh the trivial overhead of the "boilerplate" over tens of projects.

I've already explained why it helps, and I'm not lying when I say it does help. Perl is the language of AND rather than OR, and there is more than one way to do it, so I personally don't value categorical imperatives about best practices too highly.

(Also, perl -w warns you if you only use a variable once, so I don't think your example is valid. Of course, if you misspell it the same way twice, then you have problems.)

Perl is the language of AND rather than OR, and there is more than one way to do it, so I personally don't value categorical imperatives about best practices too highly.

I think best practices are quite different from categorical imperatives: at least all of the best practices I follow, I do so because I was convinced by the good arguments for them and my own experience with them. For example, I can still remember all the time I used to spend proofreading my code for typos. And I hope very few of the patterns I use are still cargo-culted :-)

I'm also a big fan of TIMTOWTDI; I think it applies in a lot of places, even including the use of strict and warnings. However, I think there's a difference between knowing all the good arguments for strict and warnings and knowing when it's ok to turn them off, and ignorance or denial of the good arguments for strict and warnings. Since this is a website for Perl help, we tend to get the latter more often than the former, so we're probably biased...

I do have to say your argument for rapid prototyping doesn't apply to me, when I'm whipping up a prototype I prefer to get all the support I can so that I don't make the kinds of silly mistakes in my prototypes that strict and warnings help to catch. So your choice seems to be simply a stylistic one (at least I don't see any technical arguments against strict), which of course you're free to make!

But also, note that people who refuse to maintain non-strict code are maybe doing so not just because of dogma, but also because they have had debugging and maintenance nightmares resulting from the absence of strict. And I also wrote a bit about why strict and warnings are appreciated on a help site like this one here. So those are some reasons why you will get pushback.