Glad to. As the reading mentioned, we've used them with event handlers and with .map() and .forEach().

They are also commonly used when we want to continue a computation but we can't wait for a value to be returned. So, instead of:

    function getSomeData() {
        ...
        return result;
    }

    function processSomeData() {
        let data = getSomeData();
        data.map(...);
    }

    processSomeData();  // starts the computation

we do:

    function getSomeData(cb) {
        ...
        cb(result);
    }

    function processSomeData(data) {
        data.map(...);
    }

    getSomeData(processSomeData); // starts the computation

The latter avoids a return statement which turns out to be crucial in some contexts, such as web requests. We'll look at this again later this semester.

There are people who argue that we shouldn't teach return at all; that everything should be done with callbacks. What do you think?

Sure. Let's look at the code

I'll draw a picture as well.

The code to serialize an object (such as a form), needs to traverse the object, visiting each input, figuring out what name it has and what value it has (easy for text boxes, but trickier for SELECT menus, radio buttons and checkboxes, and collecting the name-value pairs. The serializeArray() method does all that work for us, giving us the data in a nicely uniform data structure (though not quite convenient enough, so we convert to a dictionary).