The main deficiencies that I recall are related to RI triggers and indices not being passed on to the inherited table. You can work-around this by explicitly adding the triggers and indices after you subclass a table, but we thought that it would be very error-prone - especially on a large project like openacs4. In general we thought that it would to a large number of performance and data consistency problems that would be hard to track down.
In addition to the above-named problems, the query syntax for selecting from inherited tables is not sql3 compliant and most likely it will change in the future. Currently (or at least when we looked at it) if you select * from acs_objects, you will only get rows that correspond to items that are not part of inherited tables. In order to actually get all of the rows (including the rows in inherited tables), you need to do: select * from acs_objects*. This seems very error prone - especially since it leads to silent failures. The query returns rows, just not all of the rows that you need.
This is all I can recall right now, but I wouldn't be surprised if I'm forgetting some other issues that we discussed when first looked into using inheritance.
Overall, inheritance seemed to have alot of potential - escpecially in regards to openacs4's object model, but the postgresql implementation is just not up to the task yet.