Wow!
You definitely have a great understanding of RegExp.

This is good. You can make it a bit more concise if you update the regex from what you have to "/[105]/g".
This uses a character class, so for every character Regex looks at, it looks see if the character is either "1", "0", or "5".

This is an interesting use of a For loop inside of a Map call.
For me, the only that would make this clearer would be to rename the "len" variable to "count" or something similar.
"len" makes me think that the variable references an Array's "length".

Doh. I could have just returned "a" for the ternary's false side.

Dang. I always forget about using the spread operator to make a shallow copy of an array. Good job.

I agree that we should always try to leverage TypeScript's types. For instance, this function's signature could be more strict with its typing. But those types go away at runtime.
I believe we should still, at the very least, protect against predictable type errors such as calling "filter" on a string. Because a consumer may still send a string.

My perspective is coming from API development. But if we're talking about an arrangement of code and modules where the developer has complete control over inputs, I'd agree more with leaning into typing over runtime checks.

Array.isArray() would be a safer check for an Array here, since Strings also have "length" as a property.

Ha! I didn't even notice the parameter ordering in Reduce.
And that's an awesome reference sheet. Thank you for sharing.

That's fantastic use of the "+" unary operator.
No need for parseInt or parseFloat!