A decent UI on top of HTTP authentication would have been an improvement, and it's something that more sophisticated systems can be built on top of while maintaining compatibility.
HTTP auth doesn't make backend authentication code easier to write. In virtually all apps, it doesn't obviate the need to do session management, or solve the user demand for "remember me" cookies.
What it does do is shoehorn applications into a single inadequate login UX, one that (almost at the protocol level) is not amenable to basic security measures like gracefully logging out sessions.
Clearly there's quite a bit more wrong with HTTP auth than that (for instance, it does a terrible job of handling errors, it doesn't handle "forgot password", &c &c) but I'm not particularly interested in the counterfactual argument of what could have been had browser vendors only built a "good" version of it.
The fact remains that even the hypothetically "good" version of HTTP auth would at best be only marginally better than what we have now, and would leave all the hard problems this "definitive guide" is trying to address still on the table.
It makes it easier to shove into a library or middleware.
Most of the issues you list are UI problems that could have been solved with a non-modal login prompt, a "remember this login" option, and a "stop sending the Authentication header" button.
My point isn't that existing HTTP auth schemes are great, because they're not (even if they weren't saddled with a terrible UI). It's that migrating from those mediocre schemes would have been easier than migrating from the mediocre schemes we're using now will be.
I just disagree flat-out that HTTP authentication would have done anything to make the problems this guide is trying to grapple with easier. And in the meantime, HTTP auth as it exists in the standards today adds problems.