It isn't standard PBKDF2 but it is injecting entropy back into the process. Generally I think it is a good idea to stick with standards but it doesn't appear to be broken. IIRC it is a good idea to also include the iteration count as part of the input for each round of the hash function, although I can't remember the rationale for that decision.
But each of those 2^128 (or 2^160) "operations" would actually be 100,000 rounds of hashing if I understand correctly.
Yup that is the whole point. Imagine you have a GPU rig (8 GPUs) which can hash 1 billion passwords per second. Using a key derivation function with 100,000 iterations chops that raw throughput to 10K passwords attempts per second. Another way to look at, is assume the attacker has sufficient hardware to brute force your single hashed password in 1 minute. The same password requiring 100K iterations would take take 100,000 minutes (or ~70 days).
Usually in a key derivative function salt is also used to prevent a pre-computation attack, but as I understand it the seed in electrum is purely random thus not subject a a precomputation attack. If starting from a non-random source (i.e. Bitcoin QT wallet passphrase) a random salt should be used (it can be stored plaintext in the wallet).