If the VMs are going to get dynamic addresses from the network, why not have them act as clients on the parent network? Why have the laptop act as a router with prefix delegation?
And if they have static addresses like labs often do, NAT will already need to happen.
Only if the static addresses also need to be static global addresses, which, if you were to use NAT for network portability, they wouldn't be anyway. So what you end up with instead is two addresses on each machine: Static ULAs for internal use, SLAAC/DHCPv6 from the parent network for dynamic global addresses, and no NAT.
A response I've seen is that the relatively recent IPv4 price increases will change that. SNI routing solves that too.
In regards to the fixation on /64 being the smallest block - does it really matter to the user or operator if e.g. a /60 prefix is delegated instead of a /64 or /96 prefix? How many laptops need >16 public subnets in a single delegation, each with more addresses than they could ever hope to actually use? In the note at the end is the author really worried we'll run out of the ~4 billion /32 assignments, each of which can delegate hundreds of millions of /60s? Any of these prefix assignments are laughably wasteful for however many IPs will ever be on a laptop and there's not really much utility in them being tiny (i.e. it's not like we're about to run out of /64s to delegate). There is, however, some utility in hardware routers assuming all routing happens on the first 64 bits though. In all, I'm not sure what they are really hoping to gain by saying delegation would be better with smaller prefix sizes.
The "laptop has VMs that need to get out" use case is an interesting one though. It can be solved decently well (this is what I do personally) by a combination of link-local and/or private IPv6 IP assignments for the "internal" VM<->VM communication and letting the normal automatic SLAAC assignments handle "outbound" communication with the default route. In this method the laptop doesn't even need to route (unless you're using multiple private subnets, in which case it'll route just those). This is actually remarkably similar to the way NAT would work, sans the NAT (the difference being NAT places the dynamic assignment at a single, statefully tracked, point while in this case dynamic assignment is provided directly to each VM/container separate from the static assignments).
The big downside of this is if you are trying to emulate the exact public boundary of a production system then you want to emulate that it has everything running on 1 static public IP. For other cases in between these scenarios you can often get away with just matching any public IP in the rules. This use case "intentionally duplicate some other public network without conflicting" begs for NAT since it doesn't really change one way or the other by having as many public IPs as you'd like.
There is still upside of IPv6 even if you're in such a use case for NAT - you can just do 1:1 NAT of a private /64 to one of your delegated /64s. This drops the requirement for configuring port forwards or PAT, leaving it "true" NAT with less configuration.
See RFC 6296 and RFC 7157.
This is not simply architecture astronomy, it's the equivalent of planning an expedition to a planet to plant a flag with a title granted by the "International Star Registry"