That page never was absolutely correct and it's even less correct today.

First of all he completely ignores the possibility of deploying dual-stack networks. That's a gross omission given that dual-stack is how IPv6 was intended to be deployed for the transition period. I don't know if the author of that article just lacks knowledge of how IPv6 is intended to be deployed or if that omission is a deliberate aim to misinform the reader.

He claims that clients using IPv6 can't reach sites on IPv4 such as his. First of all it is true that his site lacks IPv6 support. And that makes his site part of the problem.

In reality I just loaded that page from an IPv6-only connection and made it through the first few paragraphs before learning that the site is legacy-only. The reason the page loaded is NAT64. There are big ISPs which have deployed that in production over 10 years ago.

Next the page claims IPv6 provides no value because the servers you can reach over IPv6 can also be reached over IPv4. Even if all servers could be reached over IPv4 (which they can't) there is still advantages from using IPv6. One major advantage is that using IPv6 avoids connections breaking due to NAT timeouts caused by the IPv4 workarounds.

The section about the necessary software changes is mostly correct. The most glaring mistake is the formatting of the example IPv6 addresses. I am not sure how the author managed to get that wrong.

Notice that those software changes have been made to enough software for that to not be a blocking issue anymore. It's advisable to still offer dual-stack to legacy devices. There does exist a DHCP option for providing dual-stack only to legacy devices and IPv6-only (with NAT64) to up-to-date clients. And there are companies who have successfully deployed that.

The next paragraph complaining that packets cannot be exchanged between IPv4 and IPv6 addresses has been debunked over and over again, because this is something that is repeatedly brought up by networking noobs.

What he was asking for was something that could not be done simply by making it part of the IPv6 specification. It would need to be part of IPv4, and every IPv4 host would need upgrading to that first. So it would double the amount of work needed to be done.

What he was asking for eventually materialized as 6to4. And it was such a disaster that it actually slowed down IPv6 deployment rather than speeding it up. In fact 6to4 was a large part of the reason Google waited until 2012 before supporting IPv6. They were waiting for the problems caused by 6to4 to be fixed first.

He is not being specific in what he is asking for. And there has been at least 8 different ways of embedding IPv4 addresses within IPv6 address space. Most of those are deprecated. Yet people to this day still suggests it would be a good idea, and we need to do that in order to deploy IPv6.

In reality half the internet has managed to upgrade using the currently available options. And for those who haven't, it's not shortcomings of IPv6 which are stopping them.