My experience is that the SECURITY extension is universal these days using MIT-MAGIC-COOKIE-1. To do otherwise would be insane as any user on the system would be able to sniff your keystrokes and mess with your windows. That would include utility users and probably even chrooted stuff.
However in this case the SECURITY extension is specifically overridden by copying the ~/.Xauthority file to the browser user. So your comment is still valid. The article discusses the performance implications of not doing the override.
I think the post is more about containing what the browser has access to in terms of Unix permissions in the event of it being controlled maliciously. The attack vector of X11 is equally applicable with or without the steps in this post.
Also, how does this setup compare with Subgraph OS which uses Xpra?
There are better alternatives:
Containers. Run your browser in a container. There are some excellent videos explaining how this works on YouTube.
VMs. Like Qubes OS. You run your browser in a separate VM as your other applications. This picture explains it rather well: https://en.wikipedia.org/wiki/Qubes_OS#/media/File:Qubes_sec...
Wayland works on FreeBSD, and I've seen some reports of it working on DragonFlyBSD as well.
http://theinvisiblethings.blogspot.de/2011/04/linux-security...
I could be wrong. Apparently X11 has the SECURITY and XACE extensions which are theoretically capable of preventing this, but nobody uses them (except SSH, see above). It's possible that DragonFlyBSD has these integrated somehow and makes the directions secure, but I don't think so.