I couldn't agree more, all too often people reach for roles cause they are shiny and then try to use them everywhere. I stress in my OSCON talk that roles are not equal to classes. That the most common usage I have found is as a replacement for something in which I would have previously used multiple inheritance. But that they should never be thought of as a replacement for inheritance a never be used in a case when classes make perfect sense.

In my experience, using both inheritance and roles makes for a more complicated (and possibly confusing) code structure.

I found that too, but now I tend to do one of two things in order to keep the role/class distinction clearer.

1. My role is an abstract interface so I have My::Thing and then several concrete classes which use the role are in My::Thing::Something (see Forest::Tree::Indexer, Forest::Tree::Reader, Forest::Tree::Writer for an example of this approach).
2. My roles are common functionality for a given set of classes (My::App::*) so I create a Roles sub-namespace (My::App::Roles::*) and stuff all these roles in there.

At one point, it turned out we needed to create a base class to extract common configuration, and the proper name for that base class would be the same name as an existing role.

Honestly, that sounds like a perfect use case for a role (or several roles), perhaps your already existing role was incorrectly named.