Historically wasn't the original design to send to the public key as the destination - there was no hash in the original design?
Then, in order to save space, the whole hashing to a public address was added on top?
That was my understanding - which is often flawed when it comes to esoteric history.
I have to say I don't know if that was historically so. But the argument "to save space" doesn't hold water in the actual implementation, because of these reasons:
1) if the public key were published instead of its hash, it wouldn't be necessary to publish it *a second time* during the signature: now people publish first the hash, and next, the public key when signing. If the address were directly the public key, one would win the hash room, because there wouldn't be any need to publish the key AGAIN.
2) the first argument actually falls down, because from the signature and the text, one can DERIVE the public key. In that way, the hash COULD win some room, because the public key never needs to be published: from the signature, one can derive it, calculate the hash, and verify whether it corresponds to the address. But this cannot be the reason, because this feature (the fact that one can calculate the public key from the signature) is not used.
3) there's a lot of other "wasting room" on the transaction, and the most important one to me is the hash of 256 bits indicating the transaction. This is overkill. There is also the 32-bit number indicating the "output number of the transaction" as if transactions would contain 4 billion outputs. This is wasted space.
In fact, the re-use of an address is what makes "indicating the transaction" necessary. If an address occurred only once, there wouldn't be any need to specify a "transaction hash": given that an address can only correspond to one single past output, that output (and its corresponding transaction) would be uniquely determined by the signature (and hence the corresponding public key, and hence the corresponding address). So there wouldn't be any need, nor to specify the transaction hash (256 bits saved) nor the output number (32 bits saved).
So I have a hard time imagining that the 100 or so bits saved by the 160 bit hash, instead of the 256 bit key, was a serious reason.
However, however, there is an extremely good reason to use a hash of a public key that is not published. That reason is: if ever the ECC crypto fails, one can still use a hash-based signature scheme (even if it is just to switch to another cryptographic signing system). The "public key" is then the "secret key" behind the hash.
==> but this scheme fails miserably if one has multiple use of the same address, because if one has used one of these in the past, then the "secret public key" is now public.
So it looks to me that the whole cryptographic design of this "hashed public key" is quite messy, even though it works. Whenever one finds a "design rationale" in one direction, there's something else that screws this:
1) winning room on the chain --> screwed by wasting room elsewhere
2) protecting public key in case ECC fails --> screwed by address multiple usage possible
That same multiple address usage also wastes a lot of space, because of the need of indicating which transaction and which output number which have way too large bit consumption for their actual needs.