It was originally designed for LDAP, so there is one example. Using a relational system almost certainly means you're using key-value structures indirectly. That's how table indexes are often implemented: a map from some key to a row coordinate (or what have you.) LMDB has been used as a backend for SQLite.
Key-value stores are primitives. Sometimes your use case needs nothing more elaborate than this primitive. Sometimes you have no choice but to limit yourself to that primitive because there are no resources for anything more complex. Often you're using it as a component of a larger storage scheme.
Mail systems are an example where you're forever looking up senders and/or recipients for some policy. Recently I've dealt with GeoIP stuff, where you're constantly resolving network addresses against a huge map. Bloom filters are a great use of a key-value store for large data sets.
Understand that often there is a lot of custom code around queries and other operations that use key-value stores. You might, for example, have some tuple that can map to multiple values in a sparse map. In that case you can iterate over variants of the tuple (selectively remove, normalize or otherwise alter parts of it,) and make multiple queries according to some precedence rule until you get a hit (or not.) There are many such tricks that will greatly extend the utility of a map.
LMDB in particular is worth understanding, even if you never use it. It has an extremely simple design that essentially makes the OS page cache into an ACID database with concurrent readers that are not blocked by writes or require coordination, and has no "transaction log." Pretty astonishing given that it boils down to about 10K LOC.