256 bit ECDSA keys have 128 bits of key strength. It requires 2^128 operations to brute force the privKey from the PubKey. This assumes the PubKey is known. If it isn't the an attacker would need to attempt a hash collision against the PubKeyHash, looking for any privKey which produces the same PubKeyHash. That would require on average 2^160 operations. Yes the PubKeyHash is oversized. Bitcoin would have similar security (when PubKey is known) is the PubKeyHash was only 128 bits (i.e. RIPEMD-128 or XOR the left and right 128 bit sequence of SHA-256).
As for key stretching reducing entropy is depends on how it is implemented. I haven't looked at Electrum source code but PBKDF2 was created to remove the entropy loss associated with PBKDF1.
But each of those 2^128 (or 2^160) "operations" would actually be 100,000 rounds of hashing if I understand correctly.
The electrum code appears to be doing a loop on the hash , but each iteration it is concatenating the output with the original seed. I don't know if this pbkdf2 (doesn't sound like it) but maybe that solves any entropy loss issue. Most probably it would, because on the last iteration you would still have all the entropy of the original seed, but you still have all those loops,to get through. Clever.
@classmethod
def stretch_key(self,seed):
oldseed = seed
for i in range(100000):
seed = hashlib.sha256(seed + oldseed).digest()
return string_to_number( seed )