Why not just use a traditional financial institution then? What's the benefit of the complexity of a blockchain if it's still unreliable without the added meatspace complexity of a bank?
Insurance via smart contracts is still far simpler and more efficient to implement than in meatspace.
Consider things like insurer solvency risk and the way that meatspace regulations make that hard to understand. With cryptocurrencies an insurer can easily offer proof of solvency based on all outstanding risks.
Insurance emerges as a fundamental economic behavior when you have investment and you have an uncertain future. There is benefit to risk pooling. Since most of us live in the first world where the traditional financial system has evolved ample insurance infrastructure, we don't always realize how remarkable it is, or how vulnerable we are to bad regulation of it.
I honestly don't know what to say about that. It's ludicrous.
Absolutely, the risk posed by a malfunctioning VM is a systemic risk that applies to the entire platform. So there is a chance that contracts impacted by a VM bug could be unreliable across the pre and post bugfix VM. The insurance contract could be one of these.
However, all things considered, I think it's interesting to contemplate a binary future "contract" about whether there will be a VM-bug-necessitated ETH hard fork in the next 30 days. What would the ideal exchange be to take a position on that future? I think it would probably be a different, but largely similar, smart contracts platform very similar to ETH, possibly even ETC.
Notably the meatspace financial system does a horrible job at identifying much less hedging against systemic risks. Identification is hard because the interactions between multiple regulatory systems and ambiguous and variable enforcement mechanisms are nearly impossible to model or to understand. It's like having a bunch of inter-related contracts all of which run on their own buggy VM.
The meatspace system seems very stable until you realize that it's highly brittle. It's impossible to meaningfully measure firm solvency risk, because the behavior of the "VM" is so unpredictable.
Actually, it's not. Regulators and ratings companies do a pretty good job of it, and in extraordinary Great Recession type events there is usually concerted response to keep consumers from incurring any losses. Insured not getting paid due to counterparty issues is a blue moon, black swan risk for business, virtual never happens to consumers.
The great thing about the modern economy is that capital is readily available, but that doesn't mean that the massive misallocation of capital over a period of decades lacks significant consequences.
Many of the dollars mis-invested into real-estate related investments brought on by tax loophole, sloppy (if not corrupt) regulation of downside risk scenarios, and the undemocratic socialization of risk via the GSEs were all things that had a massive social cost.
To argue, as the GP does, that the regulation and management of the crisis was a success by pointing to a few selected asset prices that were the focal point of knee-jerk populist reactions to the problems is a fairly absurd way to claim success.
Problems in Solidity are a systemic risk faced by all contracts and are thus not something that can be hedged within the system.
Correspondingly, fixes to VM bugs are the sort of thing that the hard fork mechanism is good for. Hard forks that fix flaky VM behavior are uncontroversial.
While there are many applications of insurance products, the use case I am referring to above has to do with specifically insuring the expected behavior of a smart contract.
Suppose I write a smart contract that "rounds up" a user's transactions for a day and donates the rest to charity. I describe the contract verbally as "This contract lists all the transactions your account made that day, rounds to the nearest ETH, and donates the difference to account xyz which is associated with the American Red Cross fundraising division.
There are several aspects of this contract to verify. First, does the logic in the code do what the verbal description says it does. Are there any mathematical errors? Can it run more than once in given 24 hour period? Is the id associated with the Red Cross actually linked to that organization?
If a trusted third party vetted the contract and claimed that its claims were true and that 800 people had used it that day to donate, I'd likely consider it worthwhile to trust that contract.
Similarly, if a third party offered an insurance smart contract that would charge me a tiny amount of Ether to guarantee that the contract would behave as expected within a 10 year period, I might feel comfortable buying that contract. If that third party was unknown to me I might rely on recommendations from others, etc.
The point is that trust builds upon trust. One sort of vetting can help buttress other layers of vetting. This is no different than trust in meatspace, only the characteristics of the blockchain make some kinds of trust easier to realize.