Oh, sure, but my point isn't about implementation complexity, it's about network architecture.
SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC.
Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change.
Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add).
For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less.
Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task.
If addresses are in a database and you set up firewall rules, you set up your clients to consistently use the same local suffix. This is approximately the same amount of work as setting up a fixed DHCP lease for a host, or setting up a static IPv4 address. Once this is done, firewall configuration is exactly the same as v4, just with a different address format.
Using a quarantine IP for new clients is a really weird way of doing things that I never saw in 5 years of working on mostly-v4 SMB enterprise environments. Clients don't support it well and never have, and revoking the lease on demand is a pain. Everyone already uses plain old firewall rules plus DNS hijacking to force people onto splash pages. If you do something that deeply weird, you're going to run into problems every time Apple slightly changes (shudder) iOS DHCP expiration logic, let alone during transition to IPv6.
You can still NAT if you want to on IPv6; you just don't have to. (In fact, NAT between an internal v6 and an external v4 network is a very widely deployed transition technology!)
Ah, well, I'll just modernize my IPAM, no big deal....
I have actually seen quarantine IPs for new clients, if memory serves - it was on MIT's wifi network in the late '00s, back when MIT still had all of 18/8 and gave everyone a public un-NATted IP (just firewalling port 25/445/etc.). You'd get a 10/8 address to connect to the captive portal, and then once you authenticated you'd have to renew your IP lease to get on the network. (They eventually switched to 802.1x and no captive portal.)
Long story short, my experience is that everyone is doing at least one silly thing with their networking ("write your own IPAM" is distressingly common, for instance), and even if everyone agrees is in fact silly, it requires some sizable project planning and expense to stop doing it. Certainly a lot of people have managed to implement IPv6 just fine - a good chunk of the internet is on IPv6. But a lot of people haven't, and I don't think the primary cause is laziness.
I mean. When it's stuff people have to do for work and they're not doing it, and that happens on a systemic level? Usually it's not "laziness", it's just that there's always lots of work and there's never enough money/man-hours.
The main point I'm trying to make is that this has nothing to do with the technical characteristics of IPv6 itself. By definition, a layer 3 protocol interacts with every single piece of network-related software out there. You have to update everything, and that's a whole lot of work no matter how you cut it. It only takes one awful hack like that MIT thing you described (whyyyyyyyyyyy) to hold up an entire migration.
(If I were MIT, I would suggest turning off router advertisements ie the infrastructure side of SLAAC, and only serving addresses over DHCPv6. Gets you an easier port of hacky shit like that.)
SLAAC doesn't work the way DHCP works. Do you have an IPAM tool that assigns addresses? Do you have a VMM/private cloud where addresses are in a database and you set up firewall rules? Do you have a guest wifi network where you assign a quarantine IP with a short lease and then a real IP once they authenticate? None of that works with SLAAC.
Especially if you have an existing IPv4 network and are rolling out dual-stack and have no interest in breaking IPv4, adding IPv6 via SLAAC is hardly a matter of adding another column in your schema. It's an architectural change.
Again, maybe that change is good, but that's the chore - not implementing the protocol (which is basically ip link | sed | ip addr add).
For privacy addresses, if you were considering implementing IPv6 before they were widespread, you'd have to figure out a way to keep from leaking them. The obvious approach is NAT, but that's effectively not an option. So you decide not to make IPv6 available to clients, only servers that already have fixed IPv4 addresses and don't roam. Or you do manual (non-SLAAC, non-DHCPv6 because that wasn't an option) configuration. Once they became available and common in people's clients, sure, but that means we didn't have "20 years" for people to offer IPv6 on guest wifi networks, we had a lot less.
Same with NATs. Implementing "not using a NAT" is absolutely trivial; you just... don't. Redesigning your network architecture not to use one, however meritorious it may be, is a massive task.