I'm not sure I'd agree that a brand new set of operators is necessarily easier to read than the template solution; particularly if you start to stack up more complex or compound uses. To borrow a suggestion which has already been given to you, consider

if(matcher(Alpha).is_none_of(Beta,Gamma,Delta) && matcher(Alpha).is_any_of(Epsilon,Zeta,Eta) && matcher(Theta).is_any_of(.....) && ...)

vs

if(Alpha [!] Beta, Gamma, Delta && Alpha[^] Epsilon, Zeta, Eta && Theta [^] ... && ....)

I'd argue cognitive load goes up from needing to track the three-character symbols and their relative positions between a bunch of names (especially consider if the names themselves become compounded names or function calls); over a more traditional function call syntax. It adds more characters, yes, but verbosity is not a dirty word if it means making the code clearer. I will agree that the need to insert a wrapping "matcher" template is unideal, but that's how the language works; and adding something as extraordinarily fundamental as a new set of operators to the language requires an extraordinary motivation which in the nicest possible way I don't quite see here.

How do you propose to construct these operators? Is [!] an operator all its own, or do the commas between terms factor in for a variable number of commas to be possibly attached to the name/definition of each of your four operators? Is A [!] B strictly equivalent to A != B or is there enough difference in how they work internally that you can't make that guarantee? I assume these aren't overloadable operators and you have a reasonable idea of details like precedence figured out - have you looked at how it would interact with the existing standard in terms of wording; including all the various fringe cases and bits that adding new operators and conditionals will have when pathologically arranged? I dread to think how many places the standard refers to operators and constructs which can be treated as conditionals and predicates, so there may well be wording awkwardness aplenty.
<https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
Kind regards,
Matthew Taylor