I think the article that's the second link returned by googling for ImpersonateSelf quite useful:
Before AdjustTokenPrivileges can be called, you must obtain a security token that will become the target of manipulation[...] it's not proper to modify the process token, although the Windows® API does allow it.
...
Due to the Windows NT® security architecture, threads normally run without a security token, [...] The right thing to do in order to avoid messing with the process state is to place a copy of the process's security token on the thread, an operation called impersonation.
...
After this step, the thread is impersonating and you can complete the operation by calling the API designed for changing the privileges on a token—AdjustTokenPrivileges.
So it's purpose is to allow a token to be modified (to e.g. enable privileges) without affecting the "global" process token.
As to the scenario you've described, I don't think sandboxing against hostile code is the purpose of the impersonation mechanisms within Windows.