Read the article - the author is saying that the same functionality provided is already implemented in a simpler and safer way.
That's why they are rejecting the patch. Because it doesn't provide anything new while adding complexity. Not because they want to avoid supporting Win32.
More code and extra abstraction layers increase the cost of maintenance and even the cost of further developments, so when adding more code the benefits have to outweigh the increase in complexity. This is also the opinion given at the end of the article.
Look, the author explains that the patch is incomplete, which I highlighted above and that it doesn't provide enough to the current functionality available already on Win32, but instead replaces a crucial component that has proven itself to work.
The patch will not make Redis behave well on Win32, Redis will still remain unusable for production environments and Redis already works well enough on Windows for development purposes.
Really, dismissing this patch is a no-brainer - and even though the author said that he prefers to keep it POSIX-only anyway, I'm sure they'll reconsider if they receive a proper patch that fixes the problem, but for the moment there is no such patch.
If there would be a patch that fixed the problem, this whole discussion would be a non-issue, even if the patch wouldn't get integrated in the main branch - somebody (if there indeed is interest) will create another branch specific for Win32 and everybody will be happy. But we can't even have a discussion of branching or not, because there is no such patch available.
Isn't the whole point of this article that Microsoft sent a patch, and it is being rejected, just to avoid supporting win32?