Right. This is totally a future thing as in "TODO" (2 lines down) and "not yet supported" (7 lines down).
We could conceivably ship without it, especially if you are right about it being a semi-fast-path optimization that noone will miss, but I DO think it could win big for NOT IN and other non-indexable cases, so I wouldn't want to put it off for very long.

The point is to bypass the p_exec-time Expression logic for certain special cases where the planner detects a hard-coded list of constants.
In this case, the planner (or maybe the ValueVectorExpression serializer) replaces the ValueVectorExpression (or its normal serialization) with the serialization of a ConstantValueExpression (distinguished by its serialized valuetype == VALUE_TYPE_ARRAY -- with a string value (serialization) that represents a JSON-friendly representation of a serialized array parameter value (elementType, length, value, value, ...). This gets serialized into a ConstantValueExpression whose persistent NValue gets deserialized at init time into with the same format as the NValue that results from an ARRAY-valued parameter OR from the ARRAY-valued result of ValueVectorExpression::eval. The benefits are a little less eval time in p_exec and probably a more compact JSON fragment. I kept them wired in even after you talked me out of them so that they could be easily benchmarked by just adding the deserialization code in NValue.cpp and matching serialization code in the planner  -- possibly limited to an experimental custom implementation of ValueVectorExpression::toJSONString. I could pull it out now or later when the smoke clears and these have turned out to be non-issues. 

An alternative optimization for eliminating lots of general cases of needless evals is to implement selective memo-ization of frequently executed but infrequently (or never) changed eval results.