In a strict sense, you're right. All a smart contract language needs to run is a linear set of inputs. However, they have a lot less utility without the other parts of a blockchain (distributed, crypto-data structure for assurance, etc.). If you don't care about being distributed, just use an API or run the external code in a container/vm.
> they refuse to abide by the decision by retroactively modifying the interpreter to interpret the contract in their favor. And why wouldn't they?
While I don't agree with the hard-fork decision, I understand (from a biz POV) why they did it. They didn't have too many options. Either hard fork or let the "hacker" collect the prize. IMO this lack of options was a failure of the EVM and solidity language itself.
While the DAO debacle had a bunch of causes but the main problems, from a language point of view, were: (a) centralized governance (upgrading/migrating) of a live contract isn't a first class citizen in solidity, (b) there's no distributed governance mechanism at all, (c) formal verification of solidity contracts is still years away.
Pact has (a) already and we'll be upgrading it to handle (b) as well next month (via a weighted vote mechanism). Either of these would have at least been able to mitigate the impact of DAO's issues -- just upgrade the contract and migrate the table the contract is guarding. Pact also has (c): https://youtu.be/Nw1glriQYP8?t=1072
A contract language has nothing to do with blockchains. All you need is a well-defined interpreter, whose interpretation all parties agree represents "the truth", and all that's left is entering into a legally binding contract which states these terms plus the "smart contract" in question.
Ethereum showed very well what happened when people enter into a non-binding (by the legal system) smart contract: they refuse to abide by the decision by retroactively modifying the interpreter to interpret the contract in their favor. And why wouldn't they?