I didn’t think any of these points were very strong.

const x = {immutableValue}

That tells me the thing is fully immutable. Whether it’s a global variable or not, that’s still nice to know when reading the code! Likewise:

let x = {immutableValue}

const x = {mutableValue}

These tell me different things. The first tells me I should look out for re-assignment, the second that I should look out for mutation of the value.

In contrast, this:

let x = {mutableValue}

Clearly has the most cognitive load. Anything could happen with this. If it’s a bigger, more complex function/whatever, “what happens to x, it could be anything” is just one more thing to fit in my head as I try to figure out what this code does. Enough little uncertainties like this, and I have to give up understanding by reading entirely, and resort to a debugger. Had the author limited the scope of what was possible, it’d be a bit easier to understand, with really no drawbacks. It’s not the end of the world, but “small, simple, easy thing I can do to make the code easier to understand for future readers” ... why not do that?

Really, I just have a somewhat FP bias, and I'd really enjoy it if const was actually immutable, since it'd be a nice concise way of expressing that. It's just not as useful as you'd think given how often it seems to be used (by contrast I almost never see anyone actually making anything immutable in JS).

I like FP too, but most languages, including FP ones, have both mutable/immutable references and mutable/immutable values. And in JS, things like strings, numbers and booleans are immutable value, plus immutable.js is quite popular for immutable data structures, especially in React+Redux apps.