Steve Nunez (who usually works with multiple BREs) posted a comment in another vendor blog post including:
"I'd hardly call TIBCO's rete implementation 'enhanced' or to have 'full rule engine capabilities'"
Strong words! So lets list what enhancements BE has over "standard BREs" in the rule engine department:
1. event processing - in other words built in channel and event support. {Most BRE's have a single, invocation interface...}
2. event cache - in other words shared storage for events and concepts, and built-in object-backing store persistence. {Most BREs rely on J2EE to do this, or have the equivalent of DBConcepts}
3. multi-threaded Rete - see the latest BE3HF and will form part of BE4 {Most BREs don't yet have good explicit thread control}
4. concept history option
5. compile-to-bytecode architecture
But BE doesn't have a few things other BREs tend to have: built-in J2EE container support, for example (BE is a J2SE component and is its own platform, for performance reasons). BE also does not have the separation of "update an object versus working memory", whereby some BREs require you to explicitly call the engine to update the WM value of an object you update in an action. Except in the context that in BE you can define concepts in-memory (local only) vs cache (shared across engines), which is somewhat different 
.
What about "full rule engine capabilities"? BE's philosophy is certainly different to "interpreted" BREs in that the rule language is "simpler". If you want to do aggregations in a condition - well you shouldn't in BE, whereas other BREs allow that with commands like "accumulate". The basic Rete architecture - mapping declarations to tuples of all combinations of those declarations then applying filters and joins per the conditions - as described in standards like OMG PRR - are what BE concentrates on.
"It's often very fustrating to express conditions when you don't have expressions as basic as a 'not' or existential operators."
You can do "not" expressions on those filters and joins, but no quantified expressions (eg if at least one tuple, if n tuples, ...etc ), or array restrictions (eg declaration X in array Y.Z). So why these "restrictions" in rules?
Well, one answer to that is that usually, quantified expressions are about statistics or aggregations on your working data. This is precisely what you'd want a query language for - and what BE provides in BQL. So the term "at least n" or "sum of" are in fact business terms that warrant declarative declarations in their own right - for example, creating an event that can be referenced in a rule.
Of course, there are some rules and event patterns which may be easier in a rule, some in a query, some in a combination... and there is probably room for more language types to support CEP and features to allow these other languages to support rules better. (Customers and partners under NDA who have seen the BE roadmap will know what I am talking about here).
AFAIK, no BRE includes a separate "query language", although some come close, eg by allowing shared / common rule conditions.This does mean that developers used to a "everything goes in the rule" approach need to change view slightly when using BE, which also includes state models, timer rules, etc to support the CEP mission.
{Note that I am not claiming the BE rule language is not going to be extended in future, nor that some of the other BRE extensions would not be useful in BE!}
