I think one of the huge issues is that when you have all your code going through an ORM, the knowledge of the underlying database is relatively unimportant. If you want to code the rails way, then asking a PostgreSQL expert for an answer will get you an answer you don't want to use. When you are doing this with Django or the like you face similar problems. "Here's how to do it in SQL" isn't necessarily an answer that will get upvotes from users of these frameworks because it provides documentation that doesn't match the culture or expectations of the userbase. And because ORMs have their own quirks, it isn't clear to me that there is necessarily a lot of crossover.
For client libraries you have similar issues. There are a lot of questions on building and using the Pg gem, for example (and it has its own tag). Similarly we have libpq, libpqxx, etc. as tags. If we want to fold client library tags into PostgreSQL, I think we'd want to do it for all, not just PHP, JDBC, etc.
So I do see a lot of use for them because they help separate the questions regarding how to directly use the database engine from questions that don't really involve looking at this issue. If we go the other way, and want to make the PostgreSQL tag as inclusive as possible, then we need to go well beyond just the hybrid tags, and look for other related tags elsewhere that need to be folded in for consistency's sake.
So I went and checked the Oracle tags, and on the front page of those with no answers ranked 1 or higher, there were 2 framework-specific questions. On the other hand, most of the PostgreSQL questions are framework-specific, so it isn't just that the tags are organized differently but that the sorts of questions we get are different.