Wow. It's just distributed signed ledgers.
Bitcoin is a massively replicated database with a single table having accountid and accountBalance, with a stored procedure that lets you transfer some of your own account's balance to any other user.
Ethereum is a massively replicated database with that same table, but you also have developer rights. You can make your own tables and stored procedures, and other people can use them.
(Some reasons that's just an analogy: they aren't actually SQL databases, Bitcoin uses UTXOs instead of accounts and has limited scripting, and Ethereum's "stored procedures" themselves have accountIds, with their own balances.)
https://www.reddit.com/r/ethereum/comments/6ettq5/statement_...
Also, it's normal practice for a contract to throw an exception if ETH is sent to any function that doesn't know how to deal with it. This includes the "fallback function," which is what runs if no other function in the contract is called. With recent versions of Solidity, this throw is built in, unless you mark a function "payable." But they were using an older contract, and there was no protection built into their fallback, and that's what made them vulnerable to this issue in the first place.
Some other things that run on Turing-complete code: passenger jets, medical equipment, self-driving cars, and nuclear reactors.
I write and audit Ethereum scripts for a living. It takes a lot of care, but it's manageable because the scripts are typically under a thousand lines total, implementing simple business rules rather than complicated algorithms. It's feasible to make it very solid if you take your time, make the code as simple and clear as possible, write lots of unit tests, hire expert review, publish the code and maybe post a bounty. It's also good practice to build in something to handle emergencies, just in case.
People are working on formal verification for Ethereum contracts, so down the road we should be able to actually prove their properties.
There is still the issue of the halting problem. But programs that would run infinitely have a finite amount of gas, and will eventually stop executing. Even if you staged an attack using a large sum of ether to fund a large amount of gas, the EVM still has a hard limit on the number of computational steps per block.
There is also still the issue of a developer writing a buggy contract (see the DAO exploit). But static analyzers and automated proofs can help address this in the future.
That's a genuine question.
The consensus rules ensures that everybody (eventually) stays on the same chain and the PoW mechanism ensures that (after a few confirmations) it would be too costly to change the blockchain for a double spend.