It costs money to execute a smart contract that writes to the blockchain, therefore they have to be as simple as possible, otherwise no one will want to use your smart contract because the transaction fees would make normal users wince.
Because the smart contract itself lives on the blockchain, that's it, unless of course it's deleted - and in the case of Ethereum (or any other EVM based smart contract) - it would need to be published with the selfdestruct() function.
Now I don't speak to that many developers, but I don't like leaving that selfdestruct() function in there.
The reason being is that one of the biggest attractions for developers into this field, is that developers are sick to the back teeth of corporates like FB, Google, Microsoft and just about every other commercial software outfit under sun, creating products with APIs for the products later to be withdrawn or functionality removed just because it's no longer in the commerical interests of that company.
Remember Google Wave? There would have been an awful lot of excited 3rd party developers who developed for that .. for the whole lot to go up in smoke.
Do you see why this isn't going away? There is a growing army of developers who are actually making money by working for protocols or DAOs without even having to disclose who they really are or having to worry about what they are building on top of, will be rug pulled from underneath them. Furthermore, their own work is very likely going to stay around for a long time to come, because the whole lot is immutable and indestructable.
Of course, simple smart contracts can go wrong, so how can they be fixed? How can upgrades be performed?
Professional smart contract developers are taught to create a proxy smart contract that uses a state value to point to the real smart contract that has the real meaty stuff.
That way, if there is anything wrong with the meaty smart contract, a new version of that can be created, with the pointer state value being updated so that the proxy smart contract calls the new meaty one.
That's yet another reason to keep it modular.
DeFi in particular is layered so no one devloper team is going to remove functionality in their smart contract.
Regarding the consequences fo smart contracts going wrong, there are a number of different insurance protocols out there - and some developers build them into their smart contracts so that users don't need to buy that insurance.
There is at least one commercial monitoring service that can constantly monitor the Ethereum mempool for any suspecious transactions related to a smart contract.
As for everyone needing to be coders, I disagree. Smart contracts tend to be generic and 99 times out of a 100, you simply be another user of the exact same smart contract. The longer a smart contract is around, the more it can be trusted.
Some products generate new smart contracts. I admit that's more complicated, but I would say the longer those products are around, the safer they are.