My argument is not against closure or using immutable objects. My argument is against trying to rebrand a problem that has been well-known and well-studied for over 40 years.
Clojure does a bit of copying (memory management, not "time management") to force you to avoid concurrency problems that arise in some scenarios. Arguably that is a good thing, because people tend to think of concurrency when it's too late. However, it too ultimately has a mutable authoritative source where the same issues arise. Moreover, the hardest concurrency and consistency problems arise in distributed systems. Using Clojure certainly isn't the answer to that.
> Isn't this the same thing as stubbornly clinging to free and malloc in programs where garbage collection would work just fine?
People "stubbornly clinge" to programming with free and malloc (in C), because it allows them to have very specific control over how their program will behave. This allows you to perform very effective optimizations. Moreover, because it is cumbersome, C programmers will avoid dynamic memory, which will again make your program faster and more durable. The same thing will apply to mutable objects. Clojure simply restricts you to a certain model, which is not necessarily most efficient.
Does that mean Clojure is bad? No it means it's not the right tool for every job.