BigInt cannot be a common approach if a language does not support it.
Once again, this kata was meant for languages which do not support big integer arithmetic, either natively, or by easily accessible libraries. JS translation was created when bigint was not in the language, and now it's considered undesired and it's planned for removal. Languages like C, C++, COBOL, are valid languages for this task. Languages like Java or C# are arguably misused: BigInteger classes can be restricted, but still the question would be whether this is reasonable, and can be done reliably enough. If the answer would be "no", the translations should be disabled too.

Currently, Codewars does not support any form of disabling translations, so we have to live with whatever got carelessly approved or did not age well. But such functionality is planned, and JS translation will be probably first to be removed from bigint kata, with possibly other languages which natively support bigint to follow.

It's also worth noting that BigInt would and should be the common approach to a problem like this, and that this kata still teaches newer programmers like myself this staple data type. A solution that doesn't use big int might be better suited to a task that isn't addition for the sake of exploring large integer handling without worrying about addition on top of it.

That's understandable. However, BigInt has been widely supported for quite a while now, so the instructions for the Kata should probably be updated to explicitly state that BigInt is to be avoided in any solutions attempted.

Yes, the reason is when the kata was published, BigInt was not available in NodeJS. Feel free to propose a better description (click fork at top page if you solved the kata, then submit your changes for approval on Discourse page).

That should be explicitly stated.

for cpp at least is for sure 4kyu

Kyus of approved katas cannot be changed, it's useless to complain about that.

I think this should be 8ku in ranking

The point of this kata is not to use BigInt.

It doesn't support BigInt

Returning inconsistent datatypes is not a best practice. [] is a perfectly good return value; there is no need to return an empty value instead of an empty array.

Don't make the same mistake Array.prototype.match makes!

No random tests

Duplicate of many filtering katas. For example