The only nit I'll pick is re: the 2nd paragraph. I do agree that there is a difference in the expressions "isEven(n)" and "0==n%2" in isolation. But these expressions will always be surrounded by more code, and the degree of difference will entirely depend on that code and its structure. All of this can be very simply solved with a quick:
function isEven(n) { return 0==n%2 }
Admittedly, I had to be conscious of how I wrote that expression, but choosing meaningful variable names is also just part of writing code, and isEven() by itself likely doesn't provide enough context about why I'm checking for even-ness to begin with. These considerations all need to go into the design of the class/method, but at no point can the developer wash their hands of the need to provide context through standard practices, just because the standard library provided more descriptive methods.
And I'm not saying this is what you're saying, but the original comment seemed to believe that more expansive standard libraries are somehow inherently better. I'd argue they're just different, and more factors to consider when choosing a language. Sometimes they help. Sometimes they're not worth the price of admission.
I think the discussion could be generalized as: how far should standard libraries go? No matter how good that standard library is, at some point, I must apply the fundamental skill of adding context and structure to the code I write.
Going back to the original, there is a difference between "isEven(n)" and "0==n%2". Sometimes (and this is definitely true in some code I write) there is a conceptual difference between asking if something is even, versus asking if it leaves a remainder of 0 upon division by 2. Yes, they can be proven to be equivalent, but the underlying intent is different.
BTW, I agree entirely that in these cases it's really mostly pointless, but the principle carries over to larger examples. Trying to see that there is a difference is probably worth it, even if we agree that it doesn't really matter in these trivial cases.
Oh, and for a compiler I used to use it really did matter that you used "foreach" when you could, versus using "for ()", because it could dispatch things in parallel in the former case, and couldn't in the latter. So expressing the intent in the code itself and not just in the context really can matter.