I've identified many cases in my employer's codebase that are something like:

    items = fetch_list_from_db()
    for item in items:
      if item.match(param):
         ..
      elif item.whatever > param2 || item.override:
         ..
      else:
         some_default_behavior()
    return custom_sort_thing(results)

In each instance, the logic is critical to business function and frequently evolving, but often underspecified, hard to audit, and each case has its own little missing features.

Prolog allows me to very easily state these rules in a way others can understand at a glance and keep them separate from the operational code. Best of it all, it solves for all possible answers (or all inputs for a given answer) without implicitly stating very much looping or recursion - even less so than functional languages in some cases.

I prototype business logic in prolog by turning client requirements into predicates. This allows me to formalize their prose and to verify I understand it correctly by asking the client for expected results for a given input/scenario. These programs never make it to production, though; I rather see them as a shadow spec.

EDIT: IMHO one should learn it just to get introduced into the mindset of declarative programming. You can implement a sufficiently fast and complete prolog easily in any language if that allows for a clearer solution to a specific problem than explicit specification of control flow.

Writing a compiler or a rules engine are fairly obvious use cases. If you have occasion to implement a simple version of either of those kinds of things, it should be a pretty decent excuse to learn some Prolog.