The point of scripts is to allow a transaction sender to create their own custom rules that define, in a totally arbitrary way, who gets to redeem it. Currently, only two styles of scripts are supported, but eventually there will be many, to support things like embedding escrow directly into the chain, etc.
This will also tie into transactions in the future. The idea is that a miner will be able to look at the transaction fee and the script, estimate how much work it will take to verify it, and decide if the fee is worth the effort or not.
In my opinion, the best thing about bitcoin is that there are these strange features that don't appear to make any sense when you first look at them, but then when you dig in, you find out that there are several nuggets of awesomeness buried there.
I agree that the script feature is very, very awesome.
I don't quite understand how the distribution of new rules are going to happen though. The current set of script rules and accepted opcodes in the client is the de facto standard for what scripts can contain. Everything described in the bitcoin wiki, and in the source code but not implemented, is just a proposal because if it's not implemented, it's not standard.
How will nonstandard clients, including newer versions of the "official" bitcoin client, be incorporated into the network? It seems to me that there are three groups of parties involved:
1) The peers that initiate transactions. They will initiate transactions with only the subset of script rules and opcodes that they know about (because that's all they can do).
2) The miners that validate transactions. They will validate transactions with only the subset of script rules and opcodes that they know about (because they want the best chance that blocks that they successfully hash will be accepted in the longest proof-of-work chain which gives them incentive to never emit blocks that have transactions that another miner might not like because it doesn't understand them).
3) The peers that want to detect a validated transaction as proof of payment. They will validate transactions with only the subset of script rules and opcodes that they know about (because that's all they can do).
There is possibly a fourth set:
4) Peers that act as pass throughs for transactions on the way from (1) to (2). They may or may not only pass on transactions that they can validate the script rules and opcodes that they know about (because they want to be good 'bitcoin citizens' and only pass on valid transactions).
If there are a variety of different subsets of the possible sript rules and opcodes permitted by subsets of each of these sets, how can anyone from set (1) feel confident that emitting anything other than the most basic script types will make it all the way through these 3 (or 4) groups?
It seems to me like there will be very, very strong pressure for bitcoin peers from all groups to maintain the lowest common denominator script rules and opcodes; and unfortunately, the lowest common denominator has already been established in the form of the current widely distributed client. How will this ever change?