Of course they don't have to. As I said, they encourage you to think in the object-orientation "encapsulate state and teach it how to mutate itself on demand" way, but you don't have to use them that way.

I'm being somewhat obtuse here, but I've never understood that.

Why would I be more likely to mutate state in sending a message to an object than I would be applying a procedure to a struct? (or a function to a record, depending on your terminology)

Immutable objects are a very old and mainstream idea, I believe they're even talked about in Effective C++.

Long history and baggage of object orientation, I suppose. There's nothing inherently mutable about dot-notation (indeed, F# uses it for accessors on immutable records as well as for "proper" object-orientation), but lots of object-oriented languages use the dot for accessing objects, and lots of object-oriented idioms involve mutation. If you're going to send a message to an object, you do kind of expect something to happen, and that's often a mutation somewhere.

Having said that, I actually don't know the history of the dot operator in any depth (https://cs.stackexchange.com/questions/89031/what-is-the-ori... suggests it arose in Simula).

> Why would I be more likely to mutate state in sending a message to an object than I would be applying a procedure to a struct?

I think most people don't think about objects in terms of sending a message to them, but in terms of calling a method on them. OOP in JS, currently, revolves a lot around mutable objects. JS itself revolves a lot around mutability. Some people are trying to change that, at least by getting proper support for the alternative. The pipeline operator is part of that.

If you don't have state what do you need an object for? Would it make more sense to have a "free" function instead?