I would; it’s a bit like teaching. For general documentation you need to refresh your mental model of the system and organize it to be explained to somebody without your familiarity. For specific areas (APIs, for example) you must review the assumptions in that domain and summarize them.

Writing _good_ documentation absolutely can be just as tiring as creating the thing being documented. It's quite common to not particularly value documentation quality and be happy with a mess of words churned out with little thought because at least it exists, but ensuring that it's accurate, covers all of the little details, and is organized well requires some careful thought and editing processes.

With a formal division between "deep thought" work and "easy" work, I'd be inclined to churn out a rough draft of documentation in the second time box but then spend at least as much time as that in the first time box cleaning it up.

TSP/PSP makes no task differentiation according to what is difficult. If it directly relates to project deliverables, then it's considered time on task.

I'd say that documentation that is expected to be used is every bit as difficult to create as good code.