We've had quite a lot of time with this change.
...and I've been wondering if we might want to revert it... Maybe even to make them bit-operations and set-operations and prefix. 
This isn't firmed up, but it's a thought that has been on my mind. Here's some reasoning.
Reason One: The Need For Non Mutating INTERSECT/UNION/etc.
In Planning Ahead for BigNum Arithmetic I discuss the tricks involved in defining variants of addition in mutating forms like ADD with a non-mutating variant like PLUS, and then enfixing PLUS as +.
I won't rewrite that post here. I'll just say that a similar issue comes up with things like INTERSECT, UNION, and DIFFERENCE...which I always thought had "mutating-sounding" names anyway. They're going to need an optimized non-mutating form that doesn't create a new numeric identity if what it makes fits in a cell.
So rather than making AND and OR and XOR some logic-heeding enfix knock-offs of THEN and ELSE, they might be better purposed to those non-mutating forms. Possibly they'd be best not even being enfix, to keep people from using them wrongly.
After all, you can make anything enfix with SHOVE:
1 >- and 2
Reason Two: Other Places To Get Our Enfix Fix
One of the arguments for why people wanted enfix conditional AND and OR is that they just fit the pacing in people's mind better. Using ANY or ALL for short-circuit evaluation has you looking at this:
if any [condition1 condition2] [
...
]
This has two prefix conditions and then two argument blocks. There's nothing breaking it up into a more natural grammar. So it's a bit of a speedbump.
But now we can say:
any [condition1 condition2] then [
...
]
I think the difference is particularly better for long condition lists:
either any [
condition1
condition2
...
conditionN
][
...
][
...
]
any [
condition1
condition2
...
conditionN
]
then [
...
]
else [
]
So you get a bit of a better pacing...something more "natural language-like". It's getting a word-in-edgewise between the blocks.
Reason Three: No Satisfying Alternative Names
I don't like bitand and friends, and I've been unhappy with and+, or+....
Reason Four: Lack of Use
Empirically I'm just not using the infix AND / OR / etc. much.
The fact that short-circuiting requires putting the right hand side in a block kills a lot of the benefits.
Then you add that to the annoyance of having to put any interesting expressions on the left in parentheses.
Pretty much everything I want to do is covered by THEN, ELSE, ALSO, and the other things that have come along. Reasoning about the AND and OR variants in these cases hasn't seemed worth the mental tax.
Reason Five: Favoring Status Quo If Benefit Not Obvious
So Ladislav made some good arguments for why this would be nice in theory...and why NOT being conditional and shoving off the non-conditionality to COMPLEMENT offers a hint that users just expect coditional operators from AND, OR, and XOR.
I guess what I'm saying here is...the benefit hasn't seemed to come across yet.
Maybe the problem is that it hasn't been done right? Perhaps AND and OR belong in a dialected situation where their expressions aren't being processed by the rules of the evaluator. LOGICAL as a analogue to MATH (or maybe just part of it?)
if math [
(some expression and some other expression)
or some expression on the next line
][
...
]
Maybe the default implementations of AND and OR don't exist at all, but point you to using this MATH dialect... where divisions also happen before additions, and things are "how people expect"?
I don't know, but I wanted to come back to this and put some of my qualms on the radar.