Good points, but I think you and the others who responded to my question are thinking about "web pages" vs what I generally create, which are responsive mobile PWAs for internal line of business apps.

> Accessibility tools

Not all applications are created for accessibility, it depends on the app and the intended audience. While in a perfect world we'd all be section 508 compliant, cash strapped startups frequently aren't in a position to invest in that for MVP.

> It often ... breaks middle-clicking

Do you use the same standard for a native app that you install from an app store? Almost everything I've written over the past decade or so has been "web tech as a replacement for native" - not a public web site, so the function comparison should be against native apps. I probably should have mentioned that in my original question.

> We already have a tag for a clickable element that is not a link: <button>

Sure, but I don't think it always makes sense semantically or from a code standpoint to use the button tag. For example, maybe I have a tiny little plus symbol for "expand". Like a lot of folks, I generally use some like font icons, or material symbols for stuff like that. Frequently it makes more sense to use a span or div to render the icon, and just handle the click event.

I'm not advocating for the use of divs instead of "a" tags everywhere, I just think there are normal and reasonable situations where it makes sense.

All engineering is a series of compromises and trade-offs. I'm not going to judge a dev that makes an info icon work to slide out a drawer which has a tabbed sub-nav, because they didn't hammer an A tag into something that it wasn't intended for, or because they didn't want to try to make whatever font icon library they're using work with a button tag.