* NAT disadvantage #3: RFC1918 was created because people were afraid of running out of addresses. (in 1992?)
Yes. One of my colleague, who participated in development of RFC 1918 confirmed it.
Your colleague was wrong. I was one of several engineers who handed out "private" addresses back before RFC1918 even though we could get "public" assignments. We did it for SMBs, large law firms, even departments of companies that were otherwise publically addressed. Nobody expressed concern for the size of the address pool (this was 1993 after all, only a year or two after uunet and psi made it possible to connect). You can confirm this by looking for references to address exhaustion in periodicals and usenet archives. It was simply not an issue until 95 or 96 at the earliest. The reason we used non-routable addresses was security and privacy. These subnets had no intention of ever communicating with "the Internet" directly. Web browsers changed that equation but the original business case for security and privacy has not changed. That business case is also why several of those otherwise legally addressed companies and departments switched to rfc1918, also before anyone gave a thought to address exhaustion.
* NAT disadvantage #5: it provides no real security. (even if it were true this could not, logically, be a disadvantage)
It is true. Lots of administrator behind the NAT thinks, that because of the NAT they can run a poor, careless software update process. Majority of the malware infection is coming from application insecurity. This cannot be prevented by NAT!
Can you site a reference? Can you substantiate "lots"? I didn't think so. This is yet another case the rhetoric gets a little over the top, leading those of us who were doing this before NAT to suspect a non-technical agenda. Roger Marquis