Firstly, what is the justification for using esoteric elliptic curve cryptography, rather than the standard public/private key cryptography as used in PGP or SSH?
As noted, the reason is ECDSA signatures are an order of magnitude smaller than RSA.
I'm not sure ECC really counts as esoteric. It's a part of SSL for some time already. It's newer than RSA but getting more popular over time.
Secondly, I find it difficult to understand the concept behind the "scripting" part of the Bitcoin client.
Scripts are not to do with network communication. They are to allow for flexible types of transactions. Today the client only generates one type of transaction - taking coins from some inputs and sending them to some outputs. But Satoshi also wanted to support things like escrow transactions, multi-claimant transactions, password protected transactions etc. Scripting allows for this to be phased in over time as new transaction types are designed.
Unfortunately Satoshi left no documentation explaining what tx types are possible or how to structure them. This is an underexplored area of the system.
Why isn't the communication between the clients done via remote procedure calls, reusing some RPC library
Satoshi felt that he couldn't have any confidence in parsing code that was complex and had many degrees of freedom. Also there aren't so many good RPC/serialization libraries out there. Protocol buffers are pretty good but by the time it was released, the code was already written.
This is a tradeoff between having flexible serialization and being able to convince yourself of its correctness by reading it. Here's a direct quote from Satoshi when I asked him the same thing:
I looked at Google protocol buffers when they were released last year, but I had already written everything by then. What I did was something similar to Boost Serialisation. For this application, where I was parsing messages from strangers who might have extreme incentive to hack the protocol, it was necessary to make it as basic as possible so I could crawl over every line of code to convince myself it was airtight. It became clear that any unnecessary degrees of freedom in the binary format multiplied the potential angles of attack. You guys are so right though to standardize across the company on protocol buffers. I think you've got the optimal solution in the general case.
As to simplification. I'm this -><- close to releasing a fairly well documented (but incomplete) Java implementation of the system. It comes with a fully JavaDocd API and some example apps. Also lots of comments. I'm hopeful this will make programming directly against the protocol less opaque.
Note that if you just want to receive/make payments, the JSON-RPC API the official client already exposes works well, is easily accessible from many languages and is how people are programming against the system today. The Java libraries being written will be primarily of interest to people who can't/don't want to use bitcoind for some reason, or who want to do lower level bitcoin hackery than what the JSON-RPC api provides.
