One can write useful rules

Programming in Notation3 can be annoying. Modeling your problem in N3 rules is not often easy. As a programmer, one wants to control tasks. Creating tasks and controlling them are neither in N3. 

For this price, one gets clarity. With no negation, the meaning of a Notation3 program is clear. The simple combinations of rules is unlikely to be deadly. Modeling something in N3 forces you to know what it is the problem actually is. At the same time, rules are a simple way of expressing, well, rules. Simple things are easy to straightforwardly say in N3.

Simply running random rules one finds is unlikely to be helpful. There are attacks against this; see \ref{evil-n3}. However, other RDF reasoning methods can be intractable also. 

This is the second point about Notation3 rules. While it is certainly possible to write rules that are very inefficient, it is sometimes an art to write efficient ones. Gaining control can be hard. In many instances, yet again, writing things in a straightforward manner is the correct amount of efficiency. Thus, the problems of control and modeling are often intertwined. 

AIR is in some ways harder to write rules for. By exposing to the programmer many control structures, it is possible to write much more efficient rules. By the same token, it is possible to write very inefficient rules. Writing the rules correctly becomes much harder. Thus, there still is not quite the control a programmer wants.

