I've really been missing this kind of functionality. Modern sites are built by people who apparently don't know or care about HTML name anchors. There is still a need to link to specific parts of pages, particularly in online discussions.
The privacy aspect seems insanely overblown to me, for the reasons you outlined.
I do understand why Brendan is using this moment to criticize this. It's on-brand (his Chromium fork has a privacy angle), and it is going to get him exposure because the supposed bad guy is Google. Don't get me wrong, they (Google) are not "good guys" by default any longer. This thing though? Not so sure. I think it will make things more good than bad, on average.
As you can tell, I think that the difference is a real, technically true difference, but the implication is a bit dumb, since authors do not have this kind of thing in mind when deciding whether to anchor. You might as well be mad about lazy image loading too. If a browser is smart enough to only load images near an anchor, then this same risk would have been opened up when that was introduced. (The author wrote the anchor before lazy loading, so they correctly perceived no risk, then lazy loading turned it into a risk.)
AFAIK we can link to any id in the page, not only to anchors. Strictly speaking you're still right because the author creates those ids but some of them are automatically created by frontend or backend frameworks.
I'm going to backpedal a bit on my point about manual scrolling being the same thing as automatically scrolling directly there via anchor.
The scrollbar can be at various positions, and if an anchor takes you there automatically, it jumps to position N, never passing through 0 .. N-1. Whereas if you manually scroll, you pass through all of 0 .. N. So whatever resources are above the target position would not necessarily be loaded with an anchor but probably would with manually scrolling. So the externally observable wire behavior (DNS, IP addresses you connect to, etc.) may still be different.
So if you manually scroll, the adversary can infer that there's something significant about scrollbar position N. It might just be that there's where you lost interest, or it could be that that's what you found interesting, but it's not giving away as direct a clue as jumping straight to position N.
If this is really an issue worth solving, doesn't it need to be solved for all cases, both traditional #foo links and also these new pattern-style links?
I can understand that this new mechanism will probably increase how often it can happen, but blocking the new mechanism would only solve part of the problem. To solve the whole problem, you'd have to do something like turn off lazy loading.
Anyway, if the reason the person is visiting the page is to read the section about cancer, aren't they usually going to manually scroll to the section about cancer a lot of the time? So the resource will still be loaded, just a little bit later. The scroll bar is moving to that position either way. The only information leaked is who moved it, the referer or the end user.