Because it was creating real directory entries that caused "." and ".." to be visible to userspace programs reading a directory, which then led to the hack in "ls" to hide them, which is where the article picks up.
It also isn't that easy to roll back once userspace programs start to rely on it - for example, the assumption that the number of files in a directory is equal to st_nlink - 2 is now so widespread that it's part of the UNIX API.
But all programs must make exceptions for these entries. Imagine trying to add a third magic filename, '...', for the grandparent for example. You would have a lot of coding to do. Not really possible. It would have been better to mark the dirs as special somehow rather than having each program have the convention programmed in.
...and of course even the kernel had to have exceptions for them anyway - it knew they were special because it had to stop userspace from unlink()ing or rename()ing them.
It also isn't that easy to roll back once userspace programs start to rely on it - for example, the assumption that the number of files in a directory is equal to st_nlink - 2 is now so widespread that it's part of the UNIX API.