Well, I would call everything you have to do besides the work itself to 'play politics'. Since very few tasks in a company require to present your work afterward, it is hard for managers to find out who did best without extra presentations.
In the end, I think it is the manager's job to motivate their people to present their work, but ultimately it is in the employee's interest.
My advice is to get used to having to present your work. Otherwise, you might end up doing a fantastic job and being disappointed when nobody notices that it was you who did it (probably resulting in promotions for people who didn't do as good as you did).
Engineering is a social job. Coding is much less of one. Explaining, debating, and presenting the relevance, correctness, quality, and comparative advantage of one's engineering work is part of "the work itself."
You're right that it's kind of pointless to "present your work afterward," and indeed, promotion committees at Google actually pay little attention to after-the-fact summaries of technical work. Instead, they look for artifacts of in-the-moment design and implementation discussions. This is the evidence showing that a given solution wasn't just one person's moment of inspired genius that he or she deigned to bestow upon the codebase, but rather the best of many possible solutions that the team chose, as a team, drawing on all the resources available such as literature, other projects past and present, the informed opinions of others in the field, the experience of senior engineers and former engineers now in management, the PMs who agree this solution achieves business goals, etc.
All too many junior engineers think a design document is "what we actually did." It's not. It's "why we picked the path we did, and why we rejected the alternatives." And yeah, as you say, nobody's going to care about what you actually did. That's kind of like being forced to look at a long series of selfies on Instagram. But they definitely will care if you asked their opinion which way to go at the start of the project, and later on they'll respect the fact that you consulted them and others on their area of expertise, because what you built has a little bit of them in it.
That's the difference between coding and engineering. Code is something that works. Engineering is the selecting the best of the possible working solutions, and being able to explain why it was the best.
In the end, I think it is the manager's job to motivate their people to present their work, but ultimately it is in the employee's interest.
My advice is to get used to having to present your work. Otherwise, you might end up doing a fantastic job and being disappointed when nobody notices that it was you who did it (probably resulting in promotions for people who didn't do as good as you did).