As others have said, there is no real need for Bitcoin scripting to be more complex than it is, as its complexity is more than enough for its intended applications; but the main reason is that not allowing some features (such as loops) in a language makes it completely deterministic: you can know for sure when and how a given program will end; you can't f.e. have infinite loops if you don't have loops in the first place, thus you don't have to worry about programs getting stuck and blocking/crashing the interpreter which is running them (in this case, the main Bitcoin software).

Not having to deal with the halting problem is definitely a plus for a tiny, embedded, purpose-specific language such as the one used for Bitcoin scripts.

It's easier to meter and restrict if it's not Turing complete, remembering that every node in the network needs to execute every script to ensure validity, we want it to be lightweight. It's not like it needs to be any more complex, nobody uses what we have to do anything interesting. Most of the opcodes are completely disabled and there's been no requests for them to be re-enabled.

There's so little use of script that I have manually inspected every single instance of a non-standandard transaction to see what they do. Other than the hash collision competitions and a lot of broken p2pool outputs, nobody to date has done anything even approaching interesting.

In other words, it's not complex because it doesn't need to be.