2 has changed. The IETF included one particular NAT mechanism called NAPT - Network Address Port Translation. This does a 1:1 mapping b/w GUA and ULA/LLAs. The advantage of this is that it provides the internal network abstraction that network admins desire, in the absence of multi-homing standards. However, one does not have to do the PAT equivalent in IPv4 and consume ports the way one did there. (So for things like mapping applications, the map can use as many ports as it likes w/o them being needed in the address translation.)
So by endorsing NAPT, the IETF came up w/ one mechanism for not just network abstraction and load balancing, but also ONE standard way for NAT lovers to implement their favorite rebel protocol in IPv6. This way, even NAT is cleaner on IPv6 than in IPv4, where you have static NAT, dynamic NAT and PAT, and what's used is usually the third.
One thing I do agree w/ you - I think the /64 assignment as the subnet size is insane, and leaves the prefix size wanting. While ARIN is generous w/ /48 assignments, both APNIC and RIPE see a potential of running out of space, and are therefore more conservative in their assignments, usually assigning /56. I happen to think that had the subnet boundary been fixed at the 96:32 mark, that would have allowed for a more rational allocation of space to the ISPs, while still allowing autoconfiguration, albeit somewhat less unique (1 in 4 billion still). The only thing ISPs would have gotten would have been /56-64s, but they'd have had the choice to allocate their customers /80 or /96, depending on how much they needed. Also, it would have been easier to organize the IPv6 internet into a globally routable hierarchy w/ really compact routing tables, and also, organizations that needed PI addresses could have gotten their own /64s which they could have then split and assigned geographically, and maybe administered/allocated directly by the IANA, as opposed to individual RIRs
