A priori, by hashing the public key, you don't win, but you LOSE space on the chain.  The reason is that you should consider an input and an output together.  A UTXO by itself is worthless if it is not spend one day.  So you have to consider both together.

Now, if in the output, you HASH the public key, you will have to publish that key openly in the corresponding future input, because otherwise, nobody will be able to check the signature.  If, on the other hand, you publish the public key at the output directly, without a hash, you don't have to repeat that at the corresponding input, you only have to specify the signature as everyone can go and get the public key to check it.  

--> hashing the public key adds a bit load equal to the hash length.

There are seemingly only two valid reasons to hash the public key:

1) you think that the public key scheme is vulnerable in the long term
2) you want to separate long term and short term security.

It is true that hashing the public key of 256 bits (which has a security of 128 bits) INCREASES its security to the level of the number of hashed bits if that number is between 128 and 256.  So it is true that a hashed key to 160 bits, is 160 bits secure, while the key itself is only 128 bits secure.  This 160 bit security is maintained until the key is published in a transaction.

However, let us make a small calculation.  Consider H the hash length, and K the key length.

Let us call long term security L, and short term security S.

Let us call B the total bit cost of an input and an output.

If there is no hashing, that is, if you directly publish the public key from its outset, then:

L = S = K/2

B_nohash = 3 K = 6 L = 6 S

(because there is the public key of length K, and the signature size is twice the key length, hence 3K)

If there is hashing, and we assume H between K and 2 K, then:

L = H

S = K / 2

B_hash = H + 3 K = L + 6 S

I will now show you why there's some craziness in this scheme:
Take Satoshi's system: L = 160 bits, S = 128 bits, which makes his B_hash(160,128) = 928.

Suppose that I would have taken L = 160 bits overall: B_nohash(160) = 960.

So I would only have used 32 bits on about 1 K more to have OVERALL SECURITY of 160 bits.

The hashing wins me 3% of room, to decrease the ECC security from 160 to 128 bits.

If I would have a direct address with a 320 bit ECC key, I would use about as much room on the block chain, as Satoshi's scheme, which LOWERS the security of ECC to 128 bit in the short term.

If I consider 128 bits enough, I would  have B_nohash(128) = 768 bits, which is about 20% less room.

In other words, apart from a suspicion on the fragility of ECC, there was no point in doing what he did.  And if there is a suspicion on that fragility, it is very wasteful to take a useless 256 bit key which would in any case easily be cracked by assumption.