Satoshi probably left it out because making a Turing-complete transaction scripting language safe is more difficult. You have to prevent scripts from running endlessly while also allowing them to run long enough to be useful, and you can't let them access too much external data or they might become invalid after being valid for a while and really screw things up. A Turing-complete transaction scripting language would be really cool, though. If done well, it could be used to add all sorts of new features (even new crypto) in a backward-compatible way.
I don't know much at all about Ethereum, but it looks like their scripts can access info about blocks, which seems dangerous. If this was possible in Bitcoin, then a reorg could cause many fully-confirmed transactions to all of a sudden become invalid by accident, without even any attacker. This is very undesirable. Maybe Ethereum does something to fix this -- I don't know.
i definitely agree that the reason this kind of functionality was not added to bitcoin was that it makes shooting oneself in the foot far easier. a related question that could be asked is "why are many of the script opcodes disabled in bitcoind?" and it has the same answer - the functionality that comes with more scripts and more opcodes is risky and creates many more corner cases to code around.
it's obviously possible to do amazing things with more powerful scripting options but i suspect it would not be sufficiently stable and secure as currently proposed in ethereum. bitcoin's success is strongly related to the fact that it is a digital currency system with a few key innovations that added a ton of value, the main innovation being the distributed public ledger. ethereum proposes sweeping changes that are not minor variations and have unknown dynamics in a real-world use case. i do quite like the ideas proposed in the ethereum proposal.