I think it's impressive how quickly the Postgres world was able to adapt to the shifting needs of webapps and the whole nosql thing. The latest JSON features are a natural extension of the key-value & array stuff that has been around for years.
There's also a bunch of working focusing on replication enhancements that is underway; adding first-party replication tooling will be a huge reliability improvement for Postgres clusters.
I don't think it's that they lost focus, it's that the project is picking up steam.
Yes you are probably right. I really like Postgres, the attitude (reliability, standards etc.), the documentation, basically everything and don't want it to change too much.
It's worth looking at things like hstore and json through the history of the project. The project has always been one which has focused on how to manage complex data in a relatively relational way, but has tended to go where no other database has gone before (table inheritance for example).
Now, it is true that when you get into the advanced capabilities of the database you run into hard edges that just don't make much sense at first, in part because they represent real disputes regarding how everything is supposed to work. Composite types in fields and table inheritance are well known for these sorts of problems but once you get used to the ideosyncracies they aren't bad.
This is true for JSON too, as there is no real way to map nested composite types to JSON constructs both ways (you can do tuple -> json, but not json -> tuple if the json object is nested). But a lot of these things just take time.
There's also a bunch of working focusing on replication enhancements that is underway; adding first-party replication tooling will be a huge reliability improvement for Postgres clusters.
I don't think it's that they lost focus, it's that the project is picking up steam.