Not quite. The computer you're referring to has one state before an event, and another state afterwards.
Modeling those as two distinct, immutable states provides enormous benefits over modeling it as a single state that "mutates". Doing this eliminates a large class of serious bugs.
The reason for these benefits is that far from trying to "escape the reality that the known universe and everything that happens within it is stateful," functional programming uses a more rigorous model of state that better reflects the relationships between states over time.
You’re points assume that OOP programs consist of a single god class stuffed full of nothing but mutable properties... which is obviously not sound OOP design.
It doesn't have to be god classes. Any mutable property that's accessible beyond a local scope raises these issues, and involves the collapsing of state over time.
That's not to say it's never valid to make the conscious engineering choice to do that, but it's a poor default to have. Functional programming languages have proved that this can be handled better.
Not necessarily - it depends on the language and how closures are implemented.
For example in Java, closures, created via lambda expressions or anonymous classes, can only access immutable ("final") variable in their enclosing scope. (At least that was true in Java 8, not sure if that was relaxed later.) So they don't export mutability of local variables. (Although they don't prevent you from mutating object fields from with a closure - again, a consequence of the host language semantics.)
Of course, closures in other imperative languages often violate FP immutability constraints. But that's only because they're given unrestricted access to the underlying imperative language features.
An interesting case is OCaml, which allows closures to mutate ref cells, e.g.:
let x = ref 5 in
let set y = x := y in
set 4;
x;;
...which outputs 4. This is compatible with OCaml's approach to mutation, and the mutable variable is at least not the default variable type - it's an explicitly mutable cell value. But this certainly breaks various good properties that immutability provides.
For example, the function `set` above provides no indication at the type level that it performs a side effect, which undermines the ability to reason about function behavior without examining the implementation.
If you want to say OCaml is only providing an FP facade which is broken by this behavior, I'm sure many Haskell programmers would agree with you. :)
If you're using them to pass around mutable state, yes.
Which is why immutable/pure-functional is always the best first choice.
If it's inconvenient to do something with pure functions, and you want to pass a bit of state around, you can use the State monad - it's 'simulated' mutable state, in that it's all pure functions under the hood, but it looks and feels like you're doing mutation.
If it's too inefficient to simulate state via the State monad, you can use state threads (ST). This is more efficient in that it compiles down to real mutations, but it's safe in that you can't share your mutations until you've exited the ST. So it should force determinism. This is what you'd use for a fast, mutable, in-place sort.
The above two solutions rule out having multiple writers, which is where STM (software transactional memory comes in). STM gives you atomic blocks which behave more or less like (in-memory) database transactions. I mainly use it for implementing workers and jobs and queues, etc.
And if you actually just want to do anything then you use IO.
It's more about being aware (in a compiler-checkable way) whether you're mutating or not than it is about outlawing mutation.
Modeling those as two distinct, immutable states provides enormous benefits over modeling it as a single state that "mutates". Doing this eliminates a large class of serious bugs.
The reason for these benefits is that far from trying to "escape the reality that the known universe and everything that happens within it is stateful," functional programming uses a more rigorous model of state that better reflects the relationships between states over time.