I'm not convinced. I think not knowing that apply() and call() exist would lead to unnecessarily clunky code, but even after over a decade of using them occasionally I still sometimes have to look up which is which. My use of them tends to end up deep in library code rather than everyday functions.

This is a crucial point. apply and call tend to be more useful for libraries than application level code, in my experience.

Even in the "front end development" subfield of web development, there are divisions. Do you want someone to produce lots of modular libraries that are reusable throughout your company/application suite, or perhaps to build a UI framework? Then knowledge of these parts of JavaScript will be very useful. Do you want someone to build a rich internet application in Meteor? Then knowledge of positioning, layouts, templates, UI effects and how to tie them into the Meteor framework is much more valuable.

Where I work we do a lot of 2D animations, so it's great if the people who work here know all about CSS transitions, requestAnimationFrame, and so on.

You should know that they exist and what they do.

You can do a lot of things with higher-order functions just by making closures, but `apply` and `call` will give you flexibility and power there's no other way to get. For one thing, they're your ticket to manipulating `this`.

The worst part is keeping them straight. My mnemonic is that `call` is just a function call, so arguments go in as normal. `apply` is the other one, so arguments go in as an array. (Maybe "A" for array, or something.)

My usual mnemonic is "call list" and "apply array"

"That said, I have a "I could learn that but I have stuff to ship" mindset about Javascript"

amen bro...amen.

Knowing call and apply demonstrates a knowledge of how context, arguments, and function calls work. It's like demonstrating pointer knowledge in C. Absolute must for a non-junior candidate (and even then, depending on what you're hiring a front-end developer for).

Yes. I have 10 people working on a code base. It's been more than a year since we started. Your hunch is correct, keeping a neat namespace is the job.