Dogmatic statements like this lead to bad, messy code. I'm a firm believer that you should use whatever style fits the problem most.

Although I agree most code would be better if people followed this dogma, sometimes mutability is just more clean/idiomatic/efficient/...

I'd agree with the first half, but not the second. Sometimes mutability allows for more concise code, although in most cases it's better to not mutate at all

Sorry, I want to make an app that works, not a perfect art piece.

Scala user unite! There are dozens of us, dozens!

That is a... strange take.

Random example, imagine a variable that holds the time of the last time the user moved the mouse. Or in a game holding the current selected target of the player. Or the players gold amount. Or its level. Or health. Or current position.

In functional programming, everything is seen as a mathematical function, which means for a given input there is a given output and there can be no side effects. Changing a variable's value is considered a side effect and is thus not possible in pure functional programming. To work around this, you typically see a lot of recursive and higher order functions.

Declaring all values as const values is something you would do if you're a diehard functional programmer, as you won't mutate any values anyway.

let there = "light"

I think using both is normal. Closures and objects are duals of each other. Do whatever is understandable and maintainable, neither paradigm is magic.

I also do that. Very simple stuff, especially of those that are easy to optimize for the compiler, are often very close to functional programming paradigms.

Avoid shared mutable state like the plague in any paradigm and you'll be fine

I use a combination of both. Objects are declared const, all members are set in the constructor, all methods are const. It doesn't really work for some types of programs (e.g. GUIs) but for stuff like number crunching it's great.