You should namespace-qualify your keywords if any code is ever going to have a chance to interact with your keywords outside of the context of your namespace. The main example I can think of is two namespaces putting keys and values into a hash-map in a third namespace, where the keys are keywords (as they often are in Clojure). A contrived example:
user> (ns main)
nil
main> (def DATA (ref {}))
#'main/DATA
main> (ns foo)
nil
foo> (dosync (alter main/DATA assoc :bad 123 ::good 123))
{:foo/good 123, :bad 123}
foo> main/DATA
#<Ref@541b02: {:foo/good 123, :bad 123}>
foo> (ns bar)
nil
bar> (dosync (alter main/DATA assoc :bad 456 ::good 456))
{:bar/good 456, :foo/good 123, :bad 456} ;; oops, no more :bad from foo
Why would you want to do this? Well, some core concepts in Clojure (like derive, for example) are implemented this way, as hash-maps in clojure.core. Multimethods also often dispatch on keyword values, and it’s not uncommon for a namespace to define a method for a multimethod in another namespace. It’s not hard to think of situations where the author of a library might like to provide a similar sort of mechanism.
It’s a good idea to namespace-qualify your keywords if there’s any risk of your keywords escaping your namespace, unless you specifically want your keywords to clobber those from other namespaces.