I kind of agree, but I explain it differently. Everyone’s job is a mix of reactive and proactive work. For my particular job, reactive work is necessary but will expand to fill all my time and then some. Proactive work is ambiguous and uncertain, but usually ends up being the highest value work that I do.

If I spend all my time on other people’s demands, it will all be urgent, but not enough of it will be important.

That's a super interesting situation (and description).

I always order reviewing the work of others ahead of working on my own code. This works wonders for the team. But admittedly, if the review workload is not distributed well, then my approach produces an annoying imbalance for me, and over the longer term, it leads to burnout.

Put differently, if I enable / assist / mentor others, that produces value comparable to my own personal output, for the company (or that's at least how I understand things). However, the emotional value of each, to me, is comparable only up to a certain extent -- namely, as long as I get to write enough code myself. The proportion must be right.

I rely on management / the team to (self-)organize the review workload, and then I prefer to help others first, and work on my own stuff second. I draw much more satisfaction from working on my own code, but I feel the importance of supporting others, so I prioritize the latter. This particular prioritization too rewards me emotionally, but only up to a certain point. I can say "no", but, in my view, if I have to say "no" frequently, to requests for assistance, then the workload is ill-distributed, and that responsibility is not mine. (I explicitly don't want to be promoted to a level where I become responsible for assigning tasks to people.)