Not a "Best Practices" at all .

Complexity is O(n^2) .

It is faster , but less space efficient .

The thing is - you cannot determine even an approximate size of the resulting vector beforehand .

Sure , the input {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16} requires the output vector to have a size equal to 16 elements .

And input {1,1,2,2,3,3,4,4,5,5,6,6,7,7,8,8} requires the output vector to have a size equal to 8 elements .

While input {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1} requires the output vector to have a size equal to just only 1 element .

Favoring speed over space is generally a good idea , but i think it is also worth knowing when "reserve" can be used with/without drawbacks .

This is kata creator fault .

Right now there is no clarification in description or test case for one particullar scenario - values with different types but with human equal values .

Solution of OP will fail such test case :
Assert.AreEqual(false, Kata.Check(new object[] { "66", 101 }, 66));

In real game/program such oversight could lead to nesty bug .

_

Double-precision floating-point moment

5 yo , but anyway .

Vectors have a reserve member function .

So , even little ineficient can be removed ... with the right situation for reserve of course :)