It's not a stupid question at all; it's an issue that people very much do not have half the history on.
Now, I get to say that, because I go all the way back to KAME which remains
the reference IPv6 implementation. Well, KAME finished up around 2006. So you'd think "oh jeez, that's even worse." Except KAME's the stack - not the protocols. The RFC for SLAAC wasn't even published in draft until 2007. Emphasis on draft;
SLAAC in fact was not formally adopted as a standard until 2015. You want to cite
RFC7527. So of course enterprise gear that adheres to formally adopted standards (and actually bothers to certify) didn't support it 3 years before it became a standard! The first drafts of SLAAC date to 2007 and were still waiting on important things like duplicate address detection, router advertisement protocol, and so on.
I've tested Archer's implementation. Unless you updated to a much later firmware, it's actually non-compliant and they can't pass an actual IPv6 certification test. Or even come close. Because it was literally a rushed implementation based on a draft RFC that contained errata compared to the adopted RFC. But it was 'close enough' for home users to not know the difference.
And if you go back to the preceding drafts, it was NEVER envisioned at the time that a routing switch would or should function as a SLAAC. Instead, it would be routers and CMTSes. Routing switches taking over L3 wasn't something anyone really clearly foresaw in 2007. Juniper, who was the class-leader in IPv6 by a wide margin (using the KAME stack from 4.11 with tweaks) at that time, wouldn't offer the EX4200 for another year. They didn't offer DS-Lite until 2010. Cisco didn't have a single-plane L3 switch at all for several more years. And so on.
People act like IPv6 has been around for years, and yes it has. But IPv4 predated DHCP by 17 years. DHCP wasn't actually a standard until 1997. This is the kind of apocrypha you don't know off the cuff - or at all - unless you've been doing this stuff a very, very, very, very long time. And so it is with IPv6. DHCPv6 was thrown together because SLAAC wasn't ready. And then it dragged on and on and on and on.
However, that gets back to "it's software, not hardware." SLAAC and radvd are strictly protocol and software implementations on top of the stack. Adding support for them does not require changing silicon in other words.
This does not mean it is just 'plug in software and go.' You have to refactor your overall design to account for these things (particularly things like BGP and OSPF.) Given the ICX6000's were released in
2012 and had a planned EOL in 2018, it was almost certainly decided that the work to put 08.0.40 (released in 2018) on systems originally based on a 2.6.32 kernel (2009, so already 3 years old at time of release) requiring a similarly antique gcc (4.4.7, 2012) for hardware that no longer fit customer profiles (not enough uplinks) was not a sound fiscal decision. Especially since most of this gear is replaced on a 3-5 year cycle anyways. So by the time things like SLAAC started mattering to customers (2018 onward) the 6000's were already on their way out to be replaced by 7000's.
Generally speaking, if you want fully working - much less cutting-edge - IPv6 support? Something made in the last 3 years isn't just recommended, it's pretty much mandatory with most vendors.