I've been told in previous questions that functional programming languages are unsuited for dynamic systems such as a physics engine, mainly because it's costly to mutate objects. How realistic is this statement, and why?
Both Haskell and Clojure allow actual mutability, so that's a non-issue to start with.
Beyond that, if your "mutable" data consists of intermediate values being updated incrementally as part of some larger computation, you may not even need mutability to be efficient! For example, there's ongoing research in Haskell regarding a technique called stream fusion, where the compiler fuses processing loops, data producers, and data consumers to eliminate intermediate data structures entirely.
The main issue with Haskell here is laziness--in a number-crunching program where you have a lot of input data and a lot of output data and all of it is important, laziness does you very few favors but still imposes some overhead. That's not to say you can't write programs like that in Haskell (people do, in fact) but it's not playing to the language's strengths and you need to have a better understanding of the evaluation model to get the performance you want.
That said, heavy number-crunching doesn't play to the strengths of the JVM, either. That sort of program is why FORTRAN is still around.
I can't speak for Clojure, but I can say Haskell has a lot of very highly tuned IO packages available that will allow all the mutation you could want.
Here's an answer to a question I wrote where someone details the 3 most common ones and regards their performance: https://stackoverflow.com/questions/15439966/when-why-use-an-mvar-over-a-tvar/15440286#15440286
You can also see here a simple graph showing performance metrics of a haskell web server called Warp, which is a highly IO intensive application.
There is a lot of confusion about this regarding Haskell, the truth is it has fantastic IO facilities with many packages on hackage for using IO in a great many different ways, many of which have been highly tuned. The reason people presume this isn't the case is because Haskell goes to great lengths to separate IO from everything else, but that has no effect on the performance characteristics.
Now to speak about performance characteristics however, the reason people recognize it as having poor performance is due to the lazy evaluation causing it to behave in ways that aren't always intuitive. This is however something you have to worry about considerably less when you start working in an IO context doing destructive updates such as in a system you are referring to. Further people tend to find that when they are having performance troubles, the built in facilities to instrument and identify where resources are going help a great deal.
Another monad worth looking at for a system like you describe would be the ST monad which is specifically for destructive updates done by very small IO calls giving it great performance.
Sorry I really can't speak to Clojure, hopefully someone else can give details there.