It depends how you measure performance. You have demonstrated that there is a performance hit - writing comments takes time. Often programmer time is the largest factor in how long it takes a program to solve a problem! Even when an program is used frequently, the few microseconds that comments may contribute to slowing down compilation of the script is nothing at all compared with the minutes spent writing them.

A better question is: are mandated comment blocks beneficial? To answer that you have to consider what sort of comments are beneficial and how the time might be better used.

Comments that describe how a piece of code works in most cases don't help much - the code should tell you that with well chosen identifiers and clear construction. Unless an algorythm is particuarly esoteric, don't comment how. In particular, don't use comments to expain how Perl works. If the syntax is fussy and the result unclear, rewrite using more conventional techniques rather than comment the issue under the carpet. The code is then less likely to break when Perl's behaviour changes or the code is refactored.

Comments describing how to call an internal sub should be minimal. If you need to know then you are dealing with internals and are either creating or maintaining internal code. Internal calling conventions tend to be somewhat mutable and because of that comments are harder to keep in sync with the actual code.

Comments describing external interfaces on the other hand describe something that should be cast in stone and should throughly describe parameters and calling context. However, that material should really be in POD rather than as integral comments.

At the end of the day mandated per sub comments really don't represent great value for money. Generally the time is better spent providing specification documentation and test code. Mandated per sub documentation is not cohesive in the way that a formal specification is, and doesn't catch errors the way a test suite does.