Inheritance hierarchies represents "is-a" relationships - one object really is another object.
That's not what tags represent. The categories in a shop don't represent is-a relationships, it's more of a "belongs to" or, in programming terms, "supports feature xy". Tags can change, they can be added and removed as you need it - base classes can't, as the object needs it! Objects don't depend on the tags you give them, but they depend on their base classes to make sense.
You can put some car in category "green cars" or "cars from the 1960's" - no problem, it doesn't care - but it can never cease to be a vehicle!
So as you see, inheritance trees and your tags model entirely different things. One is about the object itself, the other one on how we relate objects together.
True, there are cases where it makes sense for an object to have more than one base class, but these are rare and as supporting true multiple inheritance causes many other problems (that's why lots of OO languages disallow it), it's a reasonable way to model is-a hierarchies through trees.
On the other hand, your tags are represented through interfaces (for which implementing multiple ones is allowed in practically every OO langauge I know) - or better - through typeclasses, which can be added or shadowed as you need it.
I agree with you that inheritance is often overused in places where interfaces would fit better, but as both are in principle orthogonal concepts, both have their appropriate use-cases.
I'm again stressing typeclasses or concepts as they're probably the answer you were searching for, though the question works on the false premise that tags are to replace inheritance.