It could have been done that way, at the cost of increasing the amount of space it takes to store and send block headers. It seems like block header storage was a big concern for Satoshi, (there's even a section in the whitepaper about it) but it's turned out to not matter very much.
Does this mean the 2nd SHA block is padded with 64 - 16 = 48 bytes?
Yes, (source) but your reasoning is flawed. Even if the nonce space were so large that it extended into another block, that would just mean that midstate would represent the state after hashing all but the last block (block in the cryptography sense, not the Bitcoin sense.)
Also, if the block header were exactly 128 bytes, the padding would extend it to a third block. You only have 119 bytes before that happens.
That way, extranonce doesn't have to be in the generation transaction, thereby speeding up hashing, no?
Not really. You can check 2^32 hashes before incrementing extranonce, after which you only need to do ten or so hashes before you get back to mining.
Generally, in modern ASICs, even that part has been offloaded. There will be some sort of small processor within the ASIC, like an ARM core, which takes a block template as input and outputs block headers for the SHA256 cores to work on.
So the cost isn't one of speed, but complexity.
Like many things in Bitcoin, I think this is a technical decision that made sense at the time, but aged poorly.