Added.

So is [3, 2, 1] not a sorted list?

This isn't big data and this site doesn't let you use the tools necessary to solve a problem like you would with big data.

This kata has absolutely nothing to do with performance, and these tests aren't good either. If you want to talk about performance critical computing and efficiency, we'll do this in x86_64 with vector operations. You could make a blog post about that, like was recently seen in various programming communities.

Performance discussion in terms of optimizing trivialities in JS is incredibly idiotic and unproductive. V8 (the engine you're using) aims to optimize for certain patterns in code. With a good compiler things that "seem" inefficient are easily just as efficient as unreadable and unmaintainable messes produced by people trying to pretend to be a compiler. What's always more beneficial is profiling to find actual problems and this generally means obvious optimizations that are language agnostic. Do you know why immutable string concatenation is fast in V8? It's because everyone does it, and realistically other approaches that are much more prone to optimization by a runtime or a JIT have been ignored, so at the end of the day if you want to combine strings quickly, you now MUST just concatenate them because the V8 team spent their time implementing ropes and specialized handling of this case to make it the fastest approach. This is the kind of perverse "this is better just because we decided to optimize for it" garbage you get out of a completely useless focus on the performance of something that realistically wasn't important.

The classic meaningful optimization discussion is asymptotic runtime or memory use. I've actually, in real world code, reduced performance issues by orders of magnitude by fixing things like this. Or just recognizing that you don't need to compute something. Or caching. I've never, in well over a decade of maintaining massive code bases and writing code that had to process huge amounts of data in real time ever seen a single case where the tiny performance difference seen in using a for loop that's been optimized on jsperf over using idiomatic code style has been any more than a few percent of any runtime anywhere.

JS is not a language that is suited for computationally intense work. Hell, Node.js was marketed for its evented I/O which suits the everything-is-asynchronous nature of JS quite well. Concerning oneself with the idiosyncrasies of performance minutae from engine to engine and version to version is not a skill anyone is ever realistically going to pay you for, and the entire industry has recognized that by pursuing things like asm.js and now WebAssembly. Why it would even be a consideration on a website meant to pursue mastery of a language (not an engine/JIT), problem solving, and real world skills is beyond me. Idiomatic and asymptotically optimal solutions should be the goal, and in real world code that means a focus on maintainability and performance only when you know code is critical, and outside of that who cares if people want to golf on a website like Codewars to see how short their solution can be.

Nice use of generators!

People tend to switch entirely to let because the loss of hoisting prevents some of the most common errors. Remember that whole closure inside a loop problem? The classic StackOverflow question! Totally fixed by let. My recommendation would be to let anything you need to re-assign and const everything else. You end up using many more const variables the more comfortable you get with FP.

Because your expression has ^ you don't need the .charAt(0), so you could simplify this to /^[bfk]/.test(actions[i]).

These tests don't do a good job of checking for off-by-one errors. I see a lot of Math.round solutions and those are going to produce off-by-one errors depending on whether the Date is at the start or end of the day (and when the test is run).

The tests for this try to write to a global called colors -- seems like the tests should avoid using globals so the solution can't accidentally break them (i.e. no assignment to const). If I hadn't used const it'd have caused failures that were really confusing.

This kata is extremely awkward and tests more dynamic type variation than it does actually determining the last thing in a string, list, or argument list.

That's generally an antipattern / bad practice, so to see it be the primary focus of a kata here is pretty sad.

The nullability here really detracts from this kata.

Type checking in JS is an antipattern in the way it's expected in this kata. If other languages require null checks, that's also an antipattern these days. Type nullability was an epic design mistake, and idiomatic JS is written as if it's properly typed.

This is only clever brute force, I don't think the tests are hard enough given this passes them.