Typically, a /64 in IPv6 is one subnet. You're not really supposed to subdivide networks beyond that point. The first 64 bits identify the network, the last 64 bits identify the host. Under this design, if you only assign a /64 per server, that would mean you couldn't have multiple networks on that VM (which you'd want for something like Docker.)
However, this principle isn't really enforced on a technical level. Only some standards such as SLAAC actually require the network to be a /64, and since SLAAC isn't really relevant for servers, most cloud providers have been relatively stingy with their IPv6 allocations - at least compared to what RFCs actually recommend. (Which would probably be a /48 per customer, per region.)
I appreciate the push to expand address allocations a bit, so that providers aren't charging a monthly fee for every /128 and the like. But /64 seems like ridiculous overkill. Even for a premises network connected to an ISP, the optimal thing to do is to continue NATting to hide information about your network. Privacy wise I'd rather have 2^16 separate /128's scattered throughout a provider's address space, than a single /64, which will inevitably be treated as a single address by the surveillance industry. Ultimately discrete public addresses are really only needed for services, and the services I want to share are few and enumerable. At this point I do more work making sure individual nodes aren't fully connected (eg Internet of Shit) than making services reachable.
The idea behind the /64 minimum was to make auto-configuration easier - you could just stick the layer 2 ID (i.e. the MAC address) in the second half and not have to worry about collisions or stateful assignment system like DHCP. Remember that IPv6 was designed in the mid-90's, so both of these decisions seem silly now - using the MAC would be a serious privacy issue (modern operating systems use a random ID which changes frequently) and DHCP is very mature.
Yeah I was going to touch upon that. I understand where they were coming from design wise (apenwarr's post is fantastic for that - https://apenwarr.ca/log/20170810). Privacy extensions mainly seems like doubling down on an unworkable idea. I can see the hypothetical benefit on a shared network, where say a coffee shop has a /64 and you can have every single app looking like a separate device on that network to an outside observer. I just foresee the inevitable future where IP surveillance databases contain information like "this /48 hands out /64 to each end user, so treat it as one entity", rendering those extra bits as a mere liability to be mitigated.
Sure, but as the ancestor comment mentions, SLAAC has no relevance for the use-cases people in this thread want more then 64-bits for (e.g. Docker sub-networks). Since your Docker containers don't have "MAC addresses", there's no reason that you need to use 64 bits specifically to configure them. Your container runtime is perfectly positioned to assign IP addresses and subnets however it chooses to. Assigning a /72 to each container is perfectly fine.
However, this principle isn't really enforced on a technical level. Only some standards such as SLAAC actually require the network to be a /64, and since SLAAC isn't really relevant for servers, most cloud providers have been relatively stingy with their IPv6 allocations - at least compared to what RFCs actually recommend. (Which would probably be a /48 per customer, per region.)