The primary utility for an added key-value store is for attributes which need to be extended at runtime, and don't need referential integrity.
A good example of this would be a multi-tenant "personals" site where most of the search criteria were built-in (age, height, weight, marital status, etc.) but where each reseller of the service was allowed to add additional "profile items". Or a web CRM (think SugarCRM) where each salesperson was allowed to add their own "tags".
The alternatives to do this in SQL are all unpalatable: Entity-Attribute-Value tables (crappy performance, huge on-disk size), DDL at runtime (dangerous), or "option_1_id" columns (awkward & confusing to query).
Of course, if you're using Hstore for your core application data, then you're probably using the wrong database. But there's a lot of cases where applications need something like a key-value store for *just one thing*.