IMO the solution is neither. It could be some sort of best practice if interpreted as 'simple to understand'.
At most the solution should be O(n log(n)).

Not a problem anymore :)

Imagine having an input string like "ababa" - you want to count the b's.

Split on b will chop up the string into three parts - similar to what you naturally do ig the b's were replaced with a comma. In this case it will count one item too much as you are really just interrested in counting the commas.

Scan on the other hand will pick out only the b's ignoring the rest giving you a count of two b's.

Most likely you have not handled the "model" right, since the test case expecting '6' is related to this.

Well, it shouldn't return false in that case. Could it be that you are expecting a value to be something else? For a more elaborate answer you can post your current code in a comment and mark it "Spoiler content".

In case you get stuck a good check is to write out the input given - in this case "console.log(values, n)". Build your own test cases based on this and it will often help you on :)

True, need to test for using recursion if this is a requirement.

Whoo! I am very surprised by the performance! Can't remember if I had speed in mind when solwing the issue :)

The return statement is a short hand (and completely equivalent to)

if (i==0)
   return 0;
else
   return s/i;

This code is by no mean "cryptographic minimalistic".
The debate over how to write code will continue as long as some are new to coding and some have age long in-depth programming knowledge in the particular language.

This code is very consise and to the point utilising constructs available in the language. Also, even if I had not written it, it would be "easily readable" for me, yet I know my students would have a number of questions on what is going on.

Readabiliy is a matter of perspective.

Still think "This is so phony!" should return "Ths s s phn!" - shouldn't it? No test cases exist for 'y' being pronounced as a vowel ("i"-like).

Y is sometimes pronounces nearly like a 'j' - in this case, it must be kept.
When inputting "why?" output should be "wh?" (at least in my interpretation :)

Even "non-world examples" actually may be used in the real world. One of the customers for the company I work for, would not have signed if it wasn't for the "Hard Time Bomb" kata. Though it may seem like a game I made some very practical use of it.

That being said, a good spec is essential for any good solution. And it's only in the rarest of cases the spec can be one line of text. What feels natural for you to understand, may not count for a whole lot of other people. I have made that mistake professionally a number of times (but may have learned it after 'just' 20 years).
Say you should give you spec to a customer for validation - how is he/she supposed to get anything from it?
Then send the spec to another culture (in Northen Europe, India is a good example) where specs must be very exact in order to be executed as expected. You spec will most likely get a function in return which works only for those cases you have stated!

Codewars is not only about programming - writing a good kata require good examples (which you have), a good description and a bunch of good test cases. Neither of these tasks are easy - many good programmers here will definitely show you how to get around missing or bad test cases giving you some surprisingly easy code not in the spirit of your kata.
Take the comments given as a support for your kata to go "all the way".

Read the description thoroughly and you'll see why it's solved as is :-)