Eh, you and Dan are in agreement? "This task ... is still nearly entirely accidental complexity", etc.
I cannot agree with Dan, because I feel that all "computer stuff" is accidental complexity in Brooks writing context.
Some other replies change context into "from software dev perspective that is an essential complexity", now we are discussing what Fred Brooks wrote in 1987. If we change that context then I can agree with Dan, but if you want to refute argument you have to operate inside the same context.
What I see that Dan argues, is accidental complexity is not getting easier throughout the years. He does not touch anything about essential complexity being well "complex" and that we cannot do much about it. So I don't agree that you can refute whole idea based on those examples.
"For some queries, it's arguably zero — my work was necessary only because of some arbitrary quirk and there would be no work to do without the quirk. But even in cases where some kind of query seems necessary, I think it's unbelievable that essential complexity could have been more than 1% of the complexity I had to deal with."
It's very clear that the author of the post understands "essential complexity" as related to thinking about the query they need to write (data structures).
The issue is that in today's computing environments application programming is only a fraction of solving the problem of delivering the application.
They too see the essential (or inherent) complexity as being a domain and requirements related thing, but they draw the conclusion that they are somehow not part of it.
It is possible the whole app and system would be unnecessary if the essential complexity was addressed differently.
And it is also possible that due to the current way of doing things, there are new sources of essential (inherent) complexity.
Brooks couldn't have foreseen productivity gains coming from the internet and collaboration. But if you factor all that in and create a new baseline, faster machines still don't tell you what is the best way to deal with changes in requirements or how to represent a postal address so that it works internationally.