Named blocks, as opposed to functions, HIDE the external effects of the block from the reader. Using the name of the block as some kind of documentation feature is a poor choice.

Even if you want your subroutine to affect globals, you can pass globals in and return new values for globals. This "documents" your named block even better; explicitly telling the reader what this chunk of code depends on and what it changes.

$GLOBAL1 = do_stuff($GLOBAL0, $GLOBAL1);
[download]

is MUCH better than:

... set globals ...
...
do_stuff;
...
... use modified globals
[download]

I have had to read code like this (and it is very hard):

&read_input;
&calculate_this;
&calculate_that;
&write_output; # some to files others to databases
               # all in one function.

sub calculate_this { ... }
sub read_input { ... }
sub write_output { ... }
sub calculate_that { ... }
[download]

This was horrible. I was tempted to just remove the "sub" lines, but then I noticed the subs were not declared in the order they were used. As I paid more attention, some variables inside the subs were my()'ed but had the same name as globals.

We had to audit this code to make sure it was calculating money dispusements correctly. How can you audit this code?

It was painfull to read, impossible to audit, and such a rats nest it was difficult to modify. I lay most of the blame at the fact that it was using globals, locals, and named blocks. Writing functions force a certain amount of structure. Even if the structure is lame it is emminently more readable and auditable.