This is a valid question, I don't know why you (originally) got downvoted.
The answer I think, for the applications in industry at least, is that PRISM and other probabilistic programming langauges are not as developed as Prolog, a language that has been around for a good four decades now. Swi-Prolog in particular, is a free and open-source Prolog interpreter with an IDE, a graphical package and a veritable somrgasbord of libraries, including an http server, json and xml processing, encryption, interfaces to SQL and other databases etc etc etc. Swi is in active development, compatible with YAP-Prolog (currently the fastest implementation) very well supported and documented and has an active community.
It's a lot easier to setup a production environment in Prolog, especially using Swi, than in pretty much any other logic programming language, including the probabilistic logic programming ones.
Btw, I noticed that Kyndi list experience with Logtalk as a "plus" for one of their career opportunities (of course I looked :) which means that they're probably using Swi-Prolog.
But its not clear to me that encoding productions in source code adds any value over encoding them in the various other forms used by expert systems of old. Prolog also compels binary constraint satisfaction, recursive descent parsing, backtracking, and depth-first resolution — all undesirable constraints that are easily avoided using other fact representations or resolution engines.
Until the startup in question can make a compelling case for using prolog, much less avoiding the brittleness inherent in expert systems' resolution model, count me a disbeliever that their 'better way' really is.
I wouldn't say that backtracking and depth first search (not resolution) are undesirable. Far as I'm concerned they're pragmatic choices that minimise the amount of resources necessary to perform resolution theorem-proving.
One can encapsulate backtracking simply as an iterator over a stream of answers to a query. The SWI_prolog ecosystem provides a nice "logic engine" abstraction for that, see http://www.swi-prolog.org/pldoc/man?section=engines . That gives something similar to Python's yield operation. Backtracking inside an engine allows one to implement some neat algorithms in space proportional to your data, without invoking garbage collection.
I would hate for my logic engine to be required to backtrack every time a candidate interpretation was evaluated. AFAIK, prolog allows no alternative. Nor can it support the many powerful probabilistic extensions for rule-based reasoning that arose 25(?) years ago, nor the many improvements and variations on impasse resolution.
IMHO, the choice of prolog unnecessarily straitjackets a modern production system, making the engineering approach of this startup that much less powerful, flexible, or viable than it should be.
Also, the (!/0) operator allows you to prune choice-points and control backtracking so that it is not unconditional. Many Prolog implementations support (->/2) operator, as well as ((*->)/2) -- the soft cut, for more fine-grained control. SWI has a nice library for even further control over backtracking as well: http://www.swi-prolog.org/pldoc/man?section=solutionsequence....
Also good Prolog programmers usually are not overly concerned with backtracking, as they usually have strong knowledge of modes and determinism. See: http://www.swi-prolog.org/pldoc/man?section=modes. This is mostly second-nature to a skilled Prolog developer.
These days Prolog is general purpose, powerful, pattern driven programming language that (once properly learned!) can put together database, persistence, networking, NLP crunching in one modular program unit. Associating it with expert-system or rule-based programming is a typical AI-winter misconception. Well, a similar one was also floating about deep-learning during the same frosty season :-)
