What does it mean that the right level of abstraction depends on your purpose?

Too detailed is as unhelpful as too abstract — match the level to your current need.

Example: A senior engineer is debugging a production outage. She does not need the system architecture diagram that shows twelve microservices and their relationships — that is too abstract. She does not need the raw assembly instructions executing on the server CPU — that is too detailed. She needs the application logs from the specific service that is failing, the recent deployment diff, and the error stack trace. Her purpose — diagnosing a specific failure — determines the exact level of detail that will be useful. An hour later, when she writes the post-mortem for leadership, she shifts to the architecture diagram because her purpose has changed. Same system, same person, different purpose, different level.

Try this: Choose a domain you work in daily — your job, a creative project, a personal system. Write three descriptions of the same thing at three different levels of abstraction. First, write a one-sentence description so abstract that it could apply to many different domains (the superordinate level). Second, write a one-paragraph description at the level you would use to explain it to a peer (the basic level). Third, write a detailed description that captures specific mechanisms, steps, or components (the subordinate level). Now answer: which description would you use to explain your work to a stranger at a dinner party? Which would you use to onboard a new colleague? Which would you use to debug a specific problem? Notice that each question selected a different level — and that the selection was driven entirely by purpose, not by which description was most "correct."