I replied why I disagree with your anti-immutability position (not the same as disagreeing with anti-immutability in general!) in tweets, but for the benefit of the public I’ll summarize.

1. My summary of “Zamfirian anti-immutabilism” is as follows: it is highly desirable to have blockchain governance processes that can regularly implement hard forks that edit blockchain state for ethical reasons, specifically for uses like reversing thefts and losses and for interfering with applications that impose negative externalities on wider society.
2. I do not deny that minimizing negative externalities that result from decentralized processes is very valuable. My critique is not of the goal, but of feasibility of the proposed methods.
3. My problem with the proposed methods is two-fold. First, if hard forks start to be actively used as a mechanism for interfering with “undesired applications” (assuming we can effectively coordinate on what those are), then developers of undesired applications will either (i) move to other blockchains that *do* follow stronger immutability norms, or (ii) modify themselves in ways that allow them to dodge hard forks. For example, suppose a hard fork is declared to shut down some criminal DAO (“CAO”). The participants in the CAO can get together and make an emergency proposal to withdraw all funds to a new address, use on-chain privacy tools to anonymize them, use on-chain DEXes to trade them for other tokens, etc. A hard fork is NOT “smart” enough to be able to catch all of these contingencies.
4. Because a hard fork is saddled with the requirements that (i) it must be safe, (ii) users need time to verify that they consent to it, (iii) it must be distributed to everyone so everyone can update their software in time, hard forks as a tool will be inherently slower than CAOs’ (and other undesired applications’) efforts to evade them.
5. The DAO hard fork was a very unique incident, with properties that differ greatly from most other incidents of its type. Funds were stolen, there was consensus that they were stolen, and yet because of the inner workings of the DAO, funds could not be moved for 35 days, and so there was a 35-day window during which a hard fork could be developed and deployed. These circumstances were almost perfectly aligned to make the DAO hard fork an effective remedial tool. The future is rarely exactly like the past, and in the future, similar circumstances are unlikely to repeat. Instead, when a theft happens, the money will be gone within minutes. The DAO hard fork gave many people the impression that, if the political will was there, hard forks could be used as a remedial tool (or, if your political ideology is in the other direction, tool for centralized interference) more broadly, an impression that I think is incorrect.
6. Recovering from losses is perhaps the only example of a case where remedial hard forks can be of value. But loss recovery is better addressed through better secure and user-friendly wallet infrastructure.
7. Second, hard forks are inherently unscalable. We can use hard forks to remedy a few high-profile cases of harm, but that would only serve to bail out a small number of often wealthy losers from bugs, and would not remedy the long tail of much smaller losses, thefts and undesirable applications that take place. Any attempt at making it scalable would entail a layer of indirection, where users mostly trust a process to generate lists of regularly scheduled interventions. I think this is also a dystopian outcome, very easily leading to capture or centralization, and as seen by responses to EIP 867 the community seems to agree with me: http://github.com/ethereum/EIPs/issues/867
8. The EOS community actually tried to implement what is essentially EIP 867 with the ECAF ( https://cointelegraph.com/news/arbitration-on-a-governed-blockchain-eos-crisis-of-dispute-resolution ). This was met with wide disapproval by a community that was in favor of “governed blockchains” from the start, and the ECAF is no longer active.
9. Hence, I would estimate hard forks can at best eliminate a fraction of the negative externalities that blockchain-based applications can cause, at a high cost to their positive social value.
10. We should keep our minds open to remedial hard forks in extreme cases (eg. where 12% of all funds in the ecosystem are at stake), but in general, we should focus on layer-2 means of addressing negative externalities created by blockchain applications.
11. As one concrete example, from watching Ari Juels’ presentations on “criminal contracts” over a year back, I got a strong impression that most of the “truly dangerous” applications depend heavily on oracles. Centralized oracles can be pressured to lie in limited cases in order to interfere with applications when needed for the social interest, and decentralized oracles (eg. Augur) probably should adopt governance norms much closer to what you advocate to avoid being used for harm.