Not all applications are appropriate for Haskell.
But regarding what you said about time and stuff, there's a lot of research done in FRP, which explicitly deals with purity in time varying scenarios.
It cuts down on complexity massively but unfortunately, it is not fast or memory lean enough to use for AAA games. A lot of ideas have been borrowed from it and ported into imperative languages. From what I understand, React.js borrowed heavily from FRP. Elm did as well, although that is a functional language. Playing with Reflex was really fun, very mind bending, almost like magic. I'm looking into purescript for interesting libraries, specifically Concur.
To answer your first question, purity is nice because you can isolate functions and "prove" they are correct. The nice thing about purity is that they will always give the same result given the same input, which means that if you test a shit ton of random inputs and it behaves as expected, it will probably behave as expected in production.
I try to use purity in imperative languages since it makes it much easier to reason about data flow. This means that stuff is not mutated in hidden places, it is always clear where the data has changed. But OOP makes this very cumbersome. In imperative languages it means being very diligent in not modifying the arguments. This has several problems, one is that you either have to make a new datastructure to be returned or you must copy the entire object and return it instead. The cost of copying large structures is very steep. There's also a billion pitfalls with the depth of copying, you might accidentally be mutating another object's nested field because you didn't copy correctly. Not only that, copying objects is very unweildy code-wise beyond a simple shallow copy. This also means that you have to hand code every single class you want a deep copy of.
Then there's the issue of colliding programming styles. People are very used to just mutating everyhing everywhere. Which is fine, because it makes code more legible. But if you want to make pure functions, there might be problems with your team.
And finally purity goes against OOP, which uses methods for mutation and tries to encapsulate complexity. If you are shooting for a pure approach, you will probably be breaking this encapsulation and you will be left with a confusing mess of non-OOP code and OOP code, making it really hard to understand where things are happening.