That's what documentation is for.

Assuming a perfect world, in which you know which files to search in for documentation, I'd agree.

Having worked with XML::LibXML I found the documentation to be scattered over so many different files (due to a steep inheritance hierarchy) that consulting the documentation was often more work than writing a small example, and using introspection.

Can you suggest one realistic scenario where there is a need to decide between a subroutine and a method at runtime?

Suppose you write some RPC interface, and the incoming data structure tells you what method to call on a certain object. In order to give the appropriate error message when it's not possible to call the method, you need to check if the method exists prior to calling it.

You can't generally just try it, and catch a MethodDoesNotExist exception if it goes wrong, because that might be an internal error from within the called method too. And it's nice for the user to distinguish the "method does not exist" and "internal error while calling method" errors.

But the real downside of the non-distinction between subs and methods is the fact that importing utility subs from modules makes them available as methods, and even if you don't care, somebody inheriting from your class wonders what's up with those weird method calls.

This is a real problem, and has happened to the DBIx::Class users and developers. Their "solution" was namespace::autoclean, but it's really just a workaround, not a solution.