A rule engine has a database of facts, and set of rules that can inspect elements of the database, and modify, insert or delete facts. Usually the database consists of what amounts to a set of tagged structures (T V1 V2 ... Vn), each with different types of values V_i. A rule is often a pattern specifying that if some set of structure instances, have properties [some condition over the values of those structures, this may be conjunctive or disjunctive], that one or more values of of one of the matched structures gets changed, or a matched structure is deleted, or a new structure is inserted with some computed set of values. A really sophisticated rules engine treats rules as such structures, and thus can insert and delete rules, too, but this is pretty unusual. The rule engine (efficiently, and this is the hard part) determines which set of rules could match at any instant, chooses one and executes it, repeatedly. The value of this idea is that one can have an arbitrary bucket of "facts" (each represented by tagged structure) which are roughly indepedendent, and a set of rules which are similarly independent, and pour them all together in a unified way. The hope is that it is easy to define structures representing aspects of the world, and easier to define rules to manipulate them. It is a way of coding lots of disparate knowledge, and that's why the "business" guys like them. (The idea comes from the AI world).
Compiler parsers have two tasks tangled into one activity: 1) deciding if an input stream of text (broken into langauge tokens) is a legal instance of a specific programmming langauge, and 2) if so, constructing compiler data structures (typically abstract syntax trees and symbol tables) that represent the program so the rest of the compiler can generate code. Compiler people have spent about 50 years figuring out how to make this fast, and use very specialized algorithms (such as LALR parser generators with custom-coded actions per grammar rule) to get the job done.
One could arguably implement a compiler-parser with a rules engine; you'd need a datatype consisting of token streams, and other data types corresponding to AST nodes and symbol table entries. It would likely be harder to code the parser, and would be very unlikely to approach the speeed of a compiler-parser, and that's why nobody does this.
You can't use a compiler-parser to implement a rules engine, period. So, a rules engine is strictly more powerful.