Q:

why immutable programming is preferred than mutable?

what i am getting from all the available article about this topic is,
The main advantage of immutable objects is to make the concurrent programming.
so if any application uses so many threads then we can use immutability. 
here my question is: if application don't require multiple threads, still the immutable programming is preferred? because creating a new copy of the object for every single change can be very costly. (if yes why)

A:

Consider this:

class Time(t: Double) {
  private var time = t // Danger: mutable field
  def getTime = time
  def setTime(t: Double): Unit = time = t
}

val startAt = new Time(5.0)
val someOtherTime = startAt
someOtherTime.setTime(10.0)

// What does startAt.getTime return?

In this simple example, you might (or might not) be surprised to learn that, after someOtherTime.setTime(10.0) returns, startAt.getTime will have the value 10.0 instead of 5.0. Did you expect that, particularly given that startAt is a val?
Given that you've seen the code, maybe that was to be expected. However, if you just used Time without looking at its internals, I'm guessing that you'd be very surprised by that behavior. The state of mutable objects can change without you being aware of the change - particularly in a multi-threaded environment, where access to Time.time must be synchronized - but even the single-threaded case can introduce unexpected complexity.
Keeping objects immutable makes them simple to reason about. When those objects represent value types, immutability is practically essential. (Name a single value type in any major programming language or library that is not immutable.)
One further point about single-threaded vs. multi-threaded coding: if you're writing a single-threaded application, you might be tempted to ignore thread safety as an issue altogether. However, I think that's a little short-sighted in the general case. All new processors have multiple cores, and indications are that processors are going to get more and more cores in the coming years. If you want to write responsive, high-performance code, you're going to need to write multi-threaded applications, using thread-safe libraries.
If you're writing code that is not thread safe, and if it contains a lot of mutable objects exhibiting shared mutable state, then you're going to have to do a huge amount of refactoring to make it suitable for use in multi-threaded applications. On the other hand, if your objects are immutable, and have no shared mutable state, then that job is going to be a whole lot easier.
Incidentally, it is perfectly possible to use mutable state in a function, class, etc. provided that the mutable state is not shared (i.e. visible externally). That way you can have the benefits of the performance of mutable state, without the drawbacks.

