No that is entirely wrong, if the RAM wasn't necessary it would be freed regardless of how much it was. No person who writes production grade kernels just leaves memory hanging around because it's not worth cleaning it up (and certainly not every time a process exits).
The reason the memory is retained is so that it can be reported to the parent process why the process died (e.g. normal exit (error code 0), or failure, or killed by signal, etc), and retain enough information for simple diagnostic purposes. It is for that reason that page table mappings (for the little memory that is retained) and private data (for process exit status etc) is kept.
Sure they would. If zombie processes were everywhere, they'd put the effort in. How much space do you need to store info about a zombie process? It's probably 4 bytes: the exit code. I think that's all the info you get on Windows. That's the sort of thing they could do. Pack a bunch of them into one page or something perhaps? Or maybe just have 1 page each - and then it's still taking up 4KBytes rather than 64KBytes.
But zombie processes aren't everywhere. Typically they exist briefly and then get cleaned up. So even if they could take up 4 bytes, nobody's bothered writing the code to make them do that, because what's the point? If they take up 64KBytes it's just not a very pressing problem.
Sure. It's not that there's NO reason for it. But if the kernel writers thought there'd be lots of them, they would do something to reduce the amount of memory - eg, apply some data compression method to them, at least once they've been around a while (so that there would be no performance impact in typical usage).
I have a strong suspicion that the minimum process size on Windows NT is 64kB (between kernel and user pages, for Intel platforms anyway). So if you didn't treat a zombie process as "just another process" for management purposes you'd have to start having all sorts of exceptions in some very base level code (page tables, scheduler, system statistics and reporting, etc etc) just to clean up after other people who can't or won't code properly. I just can't see a kernel engineer agreeing that this was a sane thing to do (I can image how someone with a temperament like Linus would respond!).
Could be. But if it were a really big issue, I'd think that the minimum process size could be reduced, which might be a useful change in any case. After all, on the first Unix system I used, 64K was the MAXIMUM process size...
The point is that there are always tradeoffs, whose resolution is affected by how important an issue is perceived to be.
The reason the memory is retained is so that it can be reported to the parent process why the process died (e.g. normal exit (error code 0), or failure, or killed by signal, etc), and retain enough information for simple diagnostic purposes. It is for that reason that page table mappings (for the little memory that is retained) and private data (for process exit status etc) is kept.