It's not that it's 'less useful'; it's just that the only specification that you found is a JSR - which is a Java Standards Request. Pretty much all that comes after this point is speculation and potification from my personal experience.
Fundamentally, business rule systems need to be adaptable over time. The reason for a specification is to allow you to drop in one rule system in place of another at run-time without recompiling the application. Java has a history in this regards - dropping in replacement/implementation code is part of the design. C++ code doesn't lead people to think that it can be used that way - they tend to think of a C++ application as a 'single blob', and thus it's not amenable to dropping in extra classes to deal with business rules.
I personally wrote a POS application in Delphi (Object Pascal) ~15 yhears ago. When I got around to implementing customizable business rules, I used PascalScript, which allowed customization at run-time. I would have never expected the users of the system to use a compiler to build their rule-sets so I used a scripting language which allowed significant dynamic change in the application at run-time.
To answer your points:
- Rule engines tend to be written in java over c++ because of the environment being used. If you found a C++ only company, I'm sure their rule engine would be in C++
- It's an environmental choice. If you're using java, then the rule engine would be in java, if you're using C++, then the rule engine would be in C++
- Yes, that's a specification. Java loves them specifications.
- Activity - This is a 'political' point - It's not about preferences it's about deployments.