The classic situation where I would hide an if behind a method or function call is for portability. What I would do is have a module that promises a given API. Then when I load or construct objects I would - once - test for which implementation I should use and load that one. From then on I would call my API and the check for what way to do things is hidden.

This can be done with or without inheritance. Usually it works better without. Consider DBI for a practical example.

But if my API was one which came down to a situation where the offered API was relatively rich but the number of truly essential methods was small, a clean way to do this is to inherit from an abstract base class and then implement the necessary methods. Conceptually I like to compare this to tie. Now there are implicit "if" tests everywhere, all hidden within inheritance.

An example of this is LWP::Protocol. Even with all of the usual caveats about inheritance in Perl, this example strikes me as well-designed.

Yes, Perl could have a better inheritance model. And yes, inheritance is overused and misunderstood. But all that notwithstanding, there are cases where I think it is still appropriate. And keeping there from being a million if/elsif/else cases scattered through the code but instead hiding it in an interface can be one of them.