As long as you know that Prolog is just a fancy wrapper around a brute force search, then sure.
The art of efficient in prolog is understanding your database, facts, and your search space and how to trim it. If you need 3 items, search for 3 items only, don't search for all possible items then try to pick 3.
If you can figure out when to cut your search, do so.
For deterministic operations that you can meomize, do so.
If your system supports tabling use it.
Difference list is like the TCO of Prolog, the efficiency can be amazing.
The difference in performance between an average programmer and a pro prolog programmer is usually much more than you will find in other languages.
Prolog should also be very popular with developers who like pattern matching and destructuring; it's pattern-matching by unification is, er, unmatched.
Prolog is also excellent for DSLs, either usings it's built-in facility for defining new functors (unary or binary operators/keywords), or standard DCG recursive-descent parsers or more complex grammars. Prolog was designed for NLP, used for prototyping Erlang, and a major inspiration for Haskell after all.
But yeah, it involves quite a lot of backtracking, that happens when the resolution engine needs to go back and try something different. When this is a problem you can sometimes use the cut rule http://www.cse.unsw.edu.au/~billw/dictionaries/prolog/cut.ht...
What a con, I'll be sure to avoid anything like that in future.
"Prolog is just a brute force search" -> "Prolog is a brute force search"
and then reference the Gary Larson comic ( https://pics.me.me/the-far-side-by-gary-larson-3-23-hey-wait... ) where the cow suddenly realises what they've been eating is /grass/.
All libraries are "just" some code which does something so you don't have to. Even if Prolog is "just a brute force search", well in the same kind of way, regex is "just" a state machine brute-force matching against a string. It's still a useful tool.