tbh, best practise would be to use a language with a proper strict type system if you want to be sure to avoid these issues. All else is a bandaid/workaround.

Good logic

I agree, cuts out the truthy weirdness. In the 'long run'/'Big Picture' you shouldn't rely on truthy values.

What is maintainability and readability here? 0 being falsy is by language design, so anyone who's writing and reading JS should be expecting that.

Well, I mean, maybe there's a liiiiiiittle bit of sacrifice? But it's so trivial it's highly likely to not matter in practice, and is definitely not as exaggerated as that.

The function determineMembership is lifted (and should not be in function closure btw), making the code more reusable and modular. Nicer for the next dev or myself after 6 weeks to modify this code.

Agreed

Why is this voted as the best practice?

Why do we need a closure here?

How is this better than the answer by 'jhairau'? ( http://www.codewars.com/kata/reviews/5506c16fa11c0a0eef0000a3/groups/55fd43d97d94ac4d260000da )

If you're going to pull the iterator function out, might as well declare it outside openOrSenior to save re-declaring it each time?

+1 for composabel functions.
Similar approach: http://www.codewars.com/kata/reviews/55733d477fbf43cd5500000f/groups/557927c3e7f0fcbf55000064

Running tests gives me 'Test didn't pass: Unknown error'

Please report obvious cheats like this. See #48 for the report of this "solution".

:D