Retraction is largely solved. Rules engines such as Drools and Clara use the RETE algorithm, hashtable/b-tree indexes, can match against millions of rules. These work particularly well for "complex event processing" where you could could gather up events (say from a rocket starting up or a financial trade) into compound events you code against.
People who use this kind of tool
would say their tools are much better and that the "logic" of production rules is a pale shadow of what SAT solvers, theorem provers, etc. can do.
For ordinary "Business Rules", production rules engines compete against implementing the rules in ordinary code.
http://inform7.com/book/WI_1_1.html
is a toolkit for writing text adventure games in what looks like English. Just blasting through rules in order it uses defaults as a primary mechanism of control.
Production Rules and logic compete with databases in the sense that a more expressive system won't scale as well (you want to fit in the L3 cache if not the RAM) RDFS and OWL implement limited-but-useful subsets that scale better than others.
I've used production rules in data transformation one record at a time, they work well for this, but today I implement the same organizational principles in a set of Python functions that act on dicts. The production rules do
https://en.wikipedia.org/wiki/Transitive_closure
idiomatically but in the limited cases where you need that you can look it up in an algorithm book.
Production rules also are great for highly interactive systems.
I have used production rules in the control plane for a distributed data processing system where the system compiled a description of a job into a set of rules.
They are great for "internet-of-things" both because "IF-THIS-THEN-THAT" feels natural and the compound event capability.
It seems that they'd even be an answer to the asynchronous communication problem in Javascript.