Page 226 of Camel 3 says "...prototypes are taken into consideration only at compile time...". Dominus or Abigail will probably show up to correct me 30 seconds after I hit submit, but here goes at my explanation anyway. :)
Normally (without prototypes), subroutines are defined at compile time. During runtime, you'll get errors about undefined subroutines. There's too much left until runtime to verify things at compile time, what with importing and AUTOLOAD and method dispatch.
If you do something like the following -- with our without strict -- you'll get a message that indicates perl finds the construct ambiguous:
foo;
sub foo { print "Fooing!\n" }
On the other hand, if you make it clear that foo is a subroutine and not a constant in void context, it's perfectly fine:
foo();
&foo;
# or even
my $foo = \&foo;
$foo->();
sub foo { print "Fooing!\n" }
So it's not really a case of things having to be defined in the correct order because all of this happens at runtime. During compile time, Perl populates the symbol table and resolves what it can. That includes prototypes, and part of the reason seems to be so that you can use them almost as barewords just like built-in functions. That has to happen at compile time.
Dunno if that answers your question or muddies the matter. I have only seen a couple of good uses of prototypes, and rarely even think about them. | 