Having such a construct, even only internally, could be quite valuable. Consider the following expression:
{$expr: {$in: [2, "$f"]}} (related to SERVER-107804)
f must be an array, or we uassert. For array values of "f", it should be correct to rewrite this query to:
{f: {$in: [2]}}
which is of course equivalent to:
{f: {$eq: 2}}
(Note that the implicit array traversal semantics are what makes this possible!)

However: {f: {$eq: 2}} will happily match scalar 2/ filter out scalars != 2, while {$expr: {$in: [2, "$f"]}} will uassert if it sees any scalar values.

The rewrite proposed in SERVER-107804 would add {f: {$eq: 2}} as a predicate $and-ed with the original $expr, which allows us to leverage an index scan- however, we still have the entire original predicate left in the filter, when the only thing we actually need is a check for scalars that we could uassert on. Hence, if we had some kind of expression like $error, we could completely rewrite the expression to something like the following/ eliminate the $expr:
{$and: [{f: {$eq: 2}}, {$or: [{$isArray: "$f"}, \{$error: <mimic-uassert-in-$in>}]}]}

Which presumably could result in a "faster" residual filter. It would also give the optimizer a way to make such error semantics explicit (which in turn could help lowering to SBE, validating the correctness of other rewrites, and maybe even eventually allow us to do clever optimizations for the error predicate itself: could have a quick optimization time check to see if the index is even multikey for the path "f" before proceeding, or maybe after index V3 if we had extra metadata about scalars, could check that, or maybe even somehow push this into the index bounds itself)