> Generally I try to use "real objects" instead of static methods where possible. IMO this allows for a cleaner structuring of code compared to static helper classes.

Not always. In your case the client code becomes "harder". First create the instance and then the additional iterate/filter call. In this case I don't see why a class helps to structure better. Also you create an instance more each time you use it.

> So the idea is to have an object/class which represents a class hierarchy and offers methods for everything you need to do with it. If you just want to iterate over the complete hierarchy, just do for(Class<? super T> clazz : hierarchy) { ... }; If you want to filter the hierarchy or do other things with it, invoke one of the methods it offers. 

Sure, but our use case is very limited and I don't see that we need more operations on a class hierarchy. If so, I would understand the approach.

> Representing a type's hierarchy with a real object also allows for future improvements, e.g. the filter method could internally cache filtered hierarchies.

Right, caching could come in handy, but as we know caching classes is a problem in itself. And having a static helper is not generally a stopper for caching.

> Why do you think the API is misleading? To me, class hierarchies are one concept of the "domain" we're dealing with, so representing them as an object seems very natural to me. 

I want a list of classes/interfaces, that's it. I can use the ReflectionHelper method w/o even looking at it, whereas the object approach I need to understand more.