TL;DR — in the context of a state machine replication system, so-called “smart contracts” are user-defined components of the transition function. The idea that they must be immutable does not make much sense.
The essential part of a state machine replication system is the replication mechanism, also called the consensus protocol. The consensus protocol ensures that all honest nodes in the network (eventually) agree on their state, even in the presence of computer failures, network delays and possibly malicious or byzantine behaviour by some nodes.
In some systems, consensus on the current state is all that is needed. On an aircraft, for example, consensus must be reached in almost real time about the value of sensor inputs. In that context, the nodes will be tiny embedded devices with a hard-coded transition function. There is no particular need to keep track of the history of the messages transmitted between the nodes, or of the state, even though some information may end up being stored in the black box.
In many systems, however, keeping track of the history of transactions and of the successive states is desirable or even mandatory. In most areas of industry, trade, commerce and finance, we need to keep track of transactions for some time. For accounting and banking records, that time period may be mandated by law.
If possible that history should also be tamper-proof — today we tend to say: immutable. Block-chains have proven incredibly useful for doing just that. By linking together data structures with cryptographic hash functions, any tampering can be made visible. With proof-of-work, tampering can be made nigh impossible, but that is another story.
Transition function mutability
In most state machine replication systems the transition function is defined by only one owner. When the transition function is hard-wired, its modification might not be possible without replacing the hardware. In all other cases, modifying the transition function only requires some coordination between the nodes.
The first state machine replication system that was open to the public and allowed anyone to freely add their own transition function components of reasonable complexity is the Ethereum network — the first“smart contract platform”. This platform has one fundamental problem: once a smart contract is deployed, there is no built-in mechanism to modify it.
The immutability problem
Nothing in nature is immutable. Humans are living proof that it is so: if there was no evolution, we would not be here!
In a contract, a term is usually specified and termination clauses are often included. The possibility of later disagreements is generally acknowledged by specifying a governing law or by agreeing to submit to arbitration. Apart of that, in real life, contracts are sometimes renegotiated when conditions change. This applies to all contracts, commercial and personal, formal and informal.
In software development, there are situations where software, once deployed, cannot easily be modified. This is the case for embedded system software. In general however, deploying software without having the possibility to modify it later is simply reckless.
So why make smart contracts immutable?
The absence of a built-in mechanism to modify smart contracts appears to be a design flaw of early smart contract platforms. Because immutability of state history was considered critical, immutability of smart contracts came to be accepted as a feature, even a defining feature.
In reality, smart contracts are simply custom transition functions and there is no particular reason they should be immutable. In fact, there are often good reasons to plan for future upgrades and/or migrations. The downside of this is that it adds complexity to the code, thus creating a new source of potential bugs. What we really need are smart contract platforms that acknowledge this issue and provide built-in mechanisms for smart contract upgrades.
Disclaimer: the majority of Ethereum smart contracts I have written do not include mechanisms for a future upgrade or migration!