|Don't ask to ask, just ask|
Here is an answer to your rhetorical question.
The problem with using prototypes is that you are making assumptions for the person using your code about exactly how they are going to use it. Prototypes have many silent, nasty and unexpected side-effects. For instance perhaps the person using your code wants to have the parameters in an array. Oops, they need an array slice, but may not understand why. Perhaps they want to dynamically decide what goes into your second argument and so use a trinary operator. Oops, not allowed by the prototype, you need to use temporaries. Perhaps they are returning the output of a function to decide what your parameters should be. Oops, not allowed by the prototype, you need a temporary array and then a slice. Either that or multiple temporary scalars.
None of these are very intuitive bugs for me to figure out. Nor when I have to bring someone up to speed on Perl do I want to waste energy on explaining the whys and wherefores of prototype-caused errors. It is simpler to just pretend that they don't exist.
So using them, even when the usage is clear, is problematic at best. It is, in fact, very easy to achieve the same basic effect without the side-effects by a run-time check inside of the function. And the same approach will also work inside of method calls. It works no matter what order in your file the functions are declared in. Consistency and flexibility are Good. Making assumptions for your caller is Bad.
But there are more reasons not to use prototypes for checking. When you use prototypes, you are forcing yourself into a single positional style of programming. You have put on a blinker where you are disregarding the possibilities of list-based constructs, or the use of named parameter processing. But I find that using positional logic is inherently buggy (people make mistakes with what order parameters go in), and I find tremendous flexiblity in using dynamic list-based approaches where applicable.
So I find the win from prototypes to come with problems at best, and at worst trying to get it limits the kinds of solutions that can be tried. In other words they get me coming and going.
All of this is why when this topic came up what I said in chatter was, Given the choice, I would refuse to work with a programmer who understood how Perl's prototypes work, understood the gotchas, and used them liberally anyways. It would be a cognitive mismatch. What I mean by that is that working with that code would be a constant source of frustration for me. And I simply would not want to do it.