The common sentiment on forums is that the Ethereum's fork (there are two Ethereum blockchains now, which are both considered valid) is not a big deal, as combined "market capitalization" is higher than the pre-fork level.
As a person who have been a blockchain tech developer for 4 years, I strongly disagree with this sentiment, as the Ethereum's fork seriously undermines usefulness of smart contracts on public blockchains, and thus is going to affect Ethereum's future potential. (If you wonder how it is possible to be a block chain dev for 4 years: I was leading the colored coins project in 2012, and have been a CTO of ChromaWay, a blockchain tech company, since 2014.)
First, we need to clarify the definitions of smart contracts and blockchain technology.
Smart contracts were first described by Nick Szabo back in 1997. In his view, smart contracts are self-executing/self-enforcing contracts. One of examples he provides is a vending machine, which automatically provides goods for a payment. Another example is a car which might be automatically immobilised in a case of non-payment.
As we see, this concept of smart contracts is not tied to blockchains, but it's tied to valuable objects in the real world.
The concept of smart contracts got a new life with the invention of a blockchain. A blockchain can enforce rules, thus if a smart contract can be embedded in a blockchain, it will be automatically executed and enforced by the blockchain. This means there is no need to implement tamper-proof hardware, find trusted sort parties, debate about legalities: everything is implemented in software.
But there is one drawback: a blockchain only has an authority over things which happen within the blockchain. Also it isn't able to observe things outside of a blockchain. Thus pure blockchain smart contracts only work with cryptocurrencies.
For example, we can make a contract which will allow Alice and Bob to put their funds into an escrow in such a way that funds will be released only in case of a mutual agreement between Alice and Bob, or in case of a 3rd party dispute mediator (Claire) siding with one of parties. This dispute mediation contract can be implemented using a simple 2-of-3 multisig, which can be done in Bitcoin. In this case it is 100% trustless and free of counter-party risks (aside from the risk that Clair might be corrupt or will lose her private key).
But cryptocurrencies like Bitcoin have a problem that their exchange rate fluctuates wildly, so few businesses want to engage in long-term contracts involving Bitcoin. Does it mean that blockchain-based smart contracts are not useful for business?
No, it is actually possible to connect assets which exist in the real world to a blockchain using so-called user-defined assets. I believe colored coins was the first implementation (although Namecoin, which predates colored coins, could be potentially used for that too), then many other have followed: Mastercoin (Omni), Counterparty, Bitshares, NXT and so on.
Now we have a more complex arrangement where there is also an issuer who backs the blockchain asset. If we assume that the issuer is reputable and will do a payout according to the state of the blockchain, then we can use the power of blockchain-based smart contracts.
But it's debatable whether we still need a blockchain in this case. De-facto the issuer receives a cryptographic evidence that funds were transferred in a particular way, and he does payout accordingly. But this evidence doesn't need to be blockchain based. (Public key cryptography, hashes, Merkle trees etc. predate blockchains by several decades.)
But blockchains are useful, since they provide a means to synchronize the state between parties, and they help to establish consensus. Thus we can say that blockchain-based contracts are in many cases stronger (more resilient) than other cryptography-based contracts.
Cryptographic evidence can be ambiguous: e.g. Alice provides her version, which is valid. But Bob's version is valid too, yet it contradicts Alice's version. An issuer, who is going to enforce the contract in the real world cannot decide who's version is valid. But if a blockchain is involved, only one of this versions will be valid, as blockchains offer unambiguous view of the history.
There are many other ways to link a blockchain to the real world: oracles, data fees, smart property, etc. For example, the company which fucked up Ethereum, Slock.it, was going to develop blockchain-controlled smart locks which let a blockchain to control objects in the real world, thus allowing smart contracts involving physical objects.
Ethereum was designed as a neutral, Turing-complete medium for blockchain-based smart contracts, and it was expected that it can be tremendously useful in a wide variety of industries, from finance to personal electronics.
But now all of this goes down the drain, as Ethereum blockchain is no longer unambiguous.
Recall that the whole point of using blockchains in smart contracts which do not deal with cryptocurrencies was to make sure that only one version is valid. But Ethereum blockchain now exist in two versions, and all contracts which exist within in can potentially have a different state in different versions.
There are certainly ways to deal with ambiguities, for example, MakerDAO and Digix have announced that their contracts are only valid on the forked version of Ethereum blockchain. But this means that we bring human judgement and trusted third parties back to the equation.
So why bother paying Ethereum fees if it doesn't provide any hard guarantees? There are many other ways to disambiguate different versions, such as trusted timestamping, private & federated blockchains, Byzantine fault tolerant state machine replication and so on. In the end it might be easier to appoint a trusted third party which will stamp transactions as valid than to integrate with a blockchain, pay all the fees ... while still relying on a trusted third party to decide which of blockchains is valid.
Of course, smart contracts which work with cryptocurrencies (e.g. The DAO) but to stay within a public blockchain. But such contracts were not Ethereum's main goal, ethers were supposed to be used as tokens when moving various user-defined assets, they weren't supposed to be used as money.
Ethereum traders haven't yet realized that the dream that Ethereum will eventually be a "world computer" used across many industries was shattered. Most people see smart contracts as some sort of magical thing which makes things "trustless" and do not really understand the trade-offs.
I discussed blockchain matters with many people working in banks and fintech companies. (Our company was the first one to bring bank-backed tokens to a public blockchain, as far as I know.) They are already very suspicious of public blockchains, the running joke is "Are we supposed to pay Chinese miners to confirm our transactions?". But previously we could use an argument that public blockchains like Bitcoin can work flawless for years, and we assume that messy forks which can make contract states ambiguous are extremely unlikely. We no longer can assume that, as Ethereum have demonstrated that a messy fork is possible. So people will stay away from public blockchains unless they really need to work with native cryptocurrency assets.
So Ethereum didn't just screw itself up, it poisoned the well for all public blockchains.
Private and federated blockchains are obvious winners from this situation. Of course, a private/federated blockchain can be forked too, but then you'll know WHO is responsible, and you can sue them. This paradigm is much easier to deal with for bank people then the "some group of people have disagreed with other people, and now we have a fork" paradigm of public blockchains.