Good, because that (adding > complex?) has been discussed on this forum for myriads of times. Not again.
I'm not really sure what you're saying there but, I am as disinterested in discussing that as you are. That one is taken care of.

ok, so it saves a few local vars.
Or reordering into 4 big blocks, for each bool/bool variation.
It does a whole lot more than that and, I will also address the following statements of yours, all in one shot:
With the correct spacing, you achieve exactly the same.
It is just replacing each keyword by another, (and the local tmp var)
When using "if"/"else" to implement the equivalent of that EVALUATE statement, the expressions, in this case A > B and X = Z have to be retyped but, that's not the really bad part, the really bad part is that the programmer who is maintaining that code has to _read_ every statement and ensure that the conditions _match_ in every subsequent statement.
With the EVALUATE statement, the programmer knows immediately just by reading the EVALUATE statement that A > B and X = Z are the _only_ two other expressions involved. It isn't necessary to read _every_ single if/else statement to ensure the conditions are the same and to match them with every previous if/else and every if/else that follows. This makes the code significantly easier to understand and maintain and that is _not_ syntactic sugar, that is a logical flow that reflects much more accurately the program logic than a nest of if/else statements.
Just in case the advantage of the above isn't completely clear, consider this
type
TSOMERANGE = 0..20;
<more stuff here>
for i in TSOMERANGE do <statements here>
that construct is a significant improvement over
for i := low(TSOMERANGE)..high(TSOMERANGE) do < statements here>
and the reason is because in the first case the low and high bounds of the loop are expressed in a single expression, that is, atomically; whereas in the second case the programmer has to _read_ two expressions, low() and high() - which may not necessarily refer to the same type - to determine what the bounds of the for loop are.
Similarly with the EVALUATE statement, reading the EVALUATE clause tells the programmer what expressions are involved in columns 2 and 3 immediately. There is _no_ need to read every statement and ensure that the expressions in column 2 and 3 are always the same. That is not syntactic sugar, that is simply cleaner, much easier to understand and maintain code.
In addition to that, the conditions used in an if/else sequence are _not_ guaranteed to be stable/constant. For instance, if instead of variables A, B, X and Z, functions which take A, B, X and/or Z as var parameters are used and the functions change the value of the parameters A, B, X and/or Z, then using an if/else chain would not yield the correct result since the function values would potentially change every time the function is called which is necessary to evaluate each if statement.
And, if all that wasn't enough, that construction makes it much easier for the compiler to generate optimal code, i.e, code that isn't evaluating the expression in column 2 and 3 again and again and again and again... yuk!
Just for the record, I am not asking for the EVALUATE to be implemented in Pascal (though, it would be very nice if it were - I wouldn't be against it

), my intention is to show that there are control flow structures that would really improve the language. In addition to that, that construction is already in use in a major language (COBOL and possibly others) where it has proven to produce significantly more readable and maintainable code when dealing with multi-branch conditions.
Syntactic sugar. Important to your case (or style), but not to mine. (good for some, bad for other)
This last sentence refers to the many other sugar feature requests, in which this kind of statement was heavily debated already. If you must, repeat your site of the argument. Mine was stated often enough and needs no repetition (I just reiterate the thesis).
This isn't syntactic sugar unless the definition of syntactic sugar includes constructs such as, for instance, "for" and "repeat/until" loops. It is a much clearer and powerful way of expressing multi-branch conditions just as "for" and "repeat/until" loops are a much cleaner and more powerful way of implementing loops without having to resort to "goto" or some other contorted way of controlling program flow.