There is basically an entire course’s worth of subject matter in your question. (I used to do Scala training, and this topic takes at least an hour or two to even begin to do justice.)
But just to start off with the simplest reason for most serious use cases: immutable is vastly better for any sort of multi-threaded application. If you have multiple threads, then those threads can be trying to access a data structure at the same time. If that data structure is mutable, you can easily have one thread trying to access the data structure at the same time that another one is changing it, or worse, two threads trying to change it simultaneously, frequently leading to hard-to-debug inconsistencies, non-reproducibility, and data corruption. This is one of the most common sources of critical real-world bugs in mutable-centric programs, and costs enormous amounts of time, money, and reputational damage.
This can be worked around to a limited degree by extremely careful use of locks, yes. But getting locks right is much harder than most programmers realize, and the result is that most locking code is at least a little bit broken. And locking scales poorly: while you can build locks for a single data structure, it is easy to wind up with deadlocks when you have multiple lock-protected data structures, as inevitably happens when the program grows. Again, this causes huge problems.
None of which has much to do with Lists per se, mind – the point is that mutability, in general, is quite dangerous in any sort of serious multi-threaded code. (And in my experience, that’s most enterprise-grade code: I haven’t worked on a server-side single-threaded project in decades.)
By contrast, immutable data structures are inherently much more thread-safe – you can share them around, and each thread will see a single version at a time. The threads might wind up working with different “snapshot” versions of that data structure, but you generally won’t experience the sort of corruption that often arises when contending for a mutable structure. There are simpler rules that you can follow in order to make your threads play nicely together, and it is much easier to build seriously reliable large-scale systems – the sorts of bugs that plague mutable-centric code just don’t happen.
One additional point:
Correct, but mostly irrelevant – you should never append to a proper linked list. (As Scala’s implementation is.) You should always, always prepend instead – that’s what that data structure is for, and that’s O(1). If you really need to append, you should use a different data structure. In practice, that’s actually not terribly common – prepending usually works fine if you design your algorithm around it.
Generally speaking, if you’re getting O(n) behaviour without good reason, you’ve chosen the wrong data structure. There are many data structures available for exactly this reason: you pick what suits your needs.