Why?
When a data leaves a source, it passes through many different systems, each system uses a point of this data and transfers it to another system. For example, a data coming out of the database gets the first shape on a programming language, then it is kept in the necessary "stacks" and "queues" on various "pipelines", then different "threads" use the data, various "message queues" send the data to "microservices" on servers running in different locations, they use something from the data and the data ends its journey at some point. But during this journey, many different pieces of code compete to process this data, and some access and process this data first, some later.
Thats where immutability shines. If this data is not immutable, we will be dealing with possible problems during the entire journey of the data. If the first code runs a few milliseconds late for very different reasons, and the second code handles that data before and deletes the required value, it is possible that we will encounter a problem at that moment.
Software design all about making trade-offs, and immutability is no exception. Developers must carefully evaluate the specific needs of their projects and weigh the advantages of immutability against potential performance or integration challenges. In many cases, a thoughtful combination of mutable and immutable approaches can provide a well-rounded solution. The choice of whether to prioritize immutability depends on the project's needs and constraints.
By understanding its principles, devs can use this accordingly to create more reliable, maintainable, and robust software.