FWIW, the project in the article is explicitly intended to allow privilege elevation: "You have an application which runs in user context, without any administrative rights, and you need to perform some tasks which requires higher privileges."

The server can do whatever it needs to do in its higher privilege. Just when it interacts with the client connection, it lowers its privilege to the client's level. It gets the incoming data, sanitizes it, and reverts back to higher privilege to do the work. This minimizes the attack surface to the area dealing with client interaction, not the whole server. The server might link in a 3rd party XML library to sanitizes the incoming data and you don't know what the library can do. Running that in the client privilege level ensures that whatever it does only under the client's privilege.

That thread still has higher privilege write access to it's process's state, including the stacks of other threads that haven't impersonated that client. ImpersonateNamedPipeClient is a very leaky security barrier, and far from the only thing you need to know about when it comes to named pipe security.