The article says in reference to applying complex group-based permissions: "The simple is certainly simple, but the complex is truly impossible."
Clearly you haven't had to find a way to do it. :) There are a few different ways.
The easiest way to be able to apply permissions for more than one group is to create many additional groups which are unions of the others by putting the users in them. Yes, now you get to maintain these. It's best to write a tool to generate them.
If you want intersections you can do that with groups too, or by nesting subdirectories and applying the traversal permissions for each group to those.
But what if you want to mix read permission for one set of groups with write permission for another?
Well, you have to use the file's real write bit and group owner for the write permission since that's the only way to control it traditionally. Then use the parent directory's permissions to prevent read access from anyone not in the second set of groups and set the file's world-readability bit.
If you want to grant execute permission to a third set of groups -- that's a problem. That one really is impossible but execute doesn't mean much if you can read something (and it's not suid or sgid).
Please don't think I'm saying any of that is nice or preferable to POSIX or Windows ACLs, because it clearly sucks horribly for so many use cases, but it does should that it is possible to apply read/write permissions to arbitrary sets of groups if you're willing to deal with this kind of setup.