Most of what people see as "SELinux" is actually the default policy, which started out as way too strict. Then SELinux-enabled distros such as Red Hat moved to a policy that only applies to system services, and leaves user-launched binaries as if SELinux was disabled.
And even for system services, you can disable SELinux for one service (permissive mode) and leave it enabled for the rest.
This has been the case for more than 10 years, but the damage was done. It's now very hard for users even considering learning the basics (which are not hard).
Cloudflare sees over 40%, and it hasn't gone up in the last year even with the overall traffic increase. Personally, as the APNIC article also says about their own observations, I guess the overall adoption is somewhere in between.
But we have to remember that this reflects the adoption on the client side. With many high profile services still IPv4-only, the fraction of IPv6 flowing on the public Internet might be much lower.
I wonder what incentives are needed to push this forward, because it's not the same incentives as years ago for sure. We've long since exhausted new IPv4 allocations.
UX issue, and UX issues are often downplayed by engineers, leading to adoption failures.
Another such example is SELinux, which would have prevented so many vulnerabilities from being exploited, but whose poor UX also caused everyone to disable it at install time.
SELinux's UX was significantly improved many years later, but already too late to change ingrained opinions. There are a lot of ingrained opinions about IPv6 too.
There are maybe many buggy routers still out there that reset the IPv6 flow label field when they shouldn't, breaking hash-based load-balancers (the symptom is TCP connections spontaneously reset).
IIRC, a workaround was to prevent Linux from setting this field, or force-reset it on every outbound packet using netfilter.
Users doing speed tests in CGNAT may be seeing numbers that aren't exactly real for a (still) mostly IPv4 Internet.