Leo's reply reads:
"In this scenario, aren't we moving logic that would be better
expressed in a declarative form (drl) to facts that are coded in
java?"

I don't think this is an issue. Extracting a fact's property derived
from one or more constraints being true as an additional fact isn't
doing what Leo is afraid of at all. The CEs resulting in the assertion
of this inferred relation are still there in the DRL.

I'd be more worried about the consequences of using this approach
heavily, in large scale Fact DBs. Adding, to N basic entity facts O(N)
additional facts that just express the truth value of a simple or
compound constraint is bound to have some impact on resource
requirements.

-*-

It is, however, very desirable to be able to write LHS in a more
structured way, not being forced to either repeat CEs or create
additional facts establishing secondary properties (such as isAdult).

However, the abstraction technique for expressions (and this includes
the Boolean expressions in LHS) has been invented a long time ago:
functions! If we were able to define a CE function (I'll use
"property" to distinguish this from plain DRL functions) like this

   <result-type> property <name>( <fact-type> <name> ){ <expression> }

and use this in LHS the way we are used to, e.g.

  boolean property adult(  Person p){ p.age >= 18}

  rule x
  when
      Person( ..., adult == true )
  then ... end

It should also be possible to define property functions with multiple
fact arguments, or functions with additional parameters that aren't
fact types, e.g.

  double property weight( Thing t, double rho ){ t.volume*rho }

  rule y
     $m : Material( $rho : density )
    Thing( material == m, weight( $rho ) > 1000 )

-W