good call on the save_base method, carljm - that's pure laziness when i copied the snippet rather than a dive into the dire world of inheritance-based errors, and is now fixed.
The other point is interesting. I think that making a non-subclassing query set available should be optional. the models I have using this code include alternate managers, but I'm not sure this snippet in general should include them. the functionality case for being able to get at parent objects is weak. (the child object already includes all parent fields and the django ORM enforces naming conventions to keep it that way) I can imagine that you'd want to perhaps call a parent's object's methods without dealing with the subclass's inherited versions, but this use case seem rare, and it's not something that one can normally do in python so why in django?
Your performance point though i think is a very good one - yes, this can be a expensive query, esp. if there are long inheritance chains, since it takes a time proportional to the depth of inheritance (although I wouldn't advise more than one level of inheritance without a very strong reason, personally, for other reasons...). Definitely there are cases when you want to get at just the fields of the parent object as a performance optimisation... I think in that case the developer needs to be aware that this manager is an "expensive" one and they may wish to provide as an alternative the django-default "cheap" one.