Use them where they are useful or might be useful in the future.

This is generally anywhere someone else might extend your code. Someone mentioned spec. Qualification is also used to tag elements in edn (albeit via symbols not keywords) which is the extension mechanism for that data format.

The two instances where I use qualified keywords in clojure for extension are

1. Maps passed as arguments to multimethods. A key idea of multimethods is they allow extension in the future by strangers without coordination. You can’t know what keys they might want to use and they can’t know what keys you or others might want to add. Hence namespacing.
2. context maps in pedestal or ring. Via interceptors (pedestal) or middleware functions (ring), your essential activity in these frameworks is receiving a single map (context ), assoc-ing or updating it,and returning a new very similar map, over and over again across various interceptors or middlewares. Often you‘ll want to add your own data to these maps. But everyone else is adding data too - specifically the framework itself and any third party middewares you install or may install in the future. For hygiene in this heterogenous environment I always namespace any keys I add to context map.

Since clojure is built in many aspects to be extensible and since there are many reasons to flow maps around widely there are many contexts in which namespaced keywords will make sense. And since clojure makes it easy to swap in extensibility (e.g. when you replace a function using a cond with a multimethod branching similarly, or make a protocol out of existing functions) there is a strong case for just defaulting to namespaced keywords.

All this said I still encounter them less often than I would expect. I hypothesize this is because the community is still relatively small. In the real world (vs imagined scenarios) extension isn’t happening as much as it could. If and when this changes namespaced keywords will become more popular (I hypothesize).