Using a button here would be more appropriate for a few reasons:

Buttons by default have keyboard support for focusing and clicking. You’d have to manually add this to a div.

Screenreaders, scrapers, and other automated tools reading your html understand buttons and treat them differently from divs.

It’s easier for other devs to understand your code at a glance if clickable elements are buttons.

Putting a click element on a div is transparent to accessibility systems. And no, it isn't possible to consider an element with an onclick the same as a button, because events bubble, which means the element with the event listener isn't necessarily the element being watched for a click. IIRC there even used to be a "good practice" where people would attach a single click handler at the root and use it to dispatch events based on the `event.target` instead of attaching a separate handler to each target.

React does that, they call it synthetic events, but it's hidden from the developer. In jQuery it used to be called event delegation, made it easy to handle events on dynamic elements without the need to constantly attach/detach handlers.

Because the user can't hover over it and see where the link goes. Because the click handler represents a Javascript program that has to be downloaded. Because it can't be used with Javascript turned off -- which is increasingly necessary these days since ad networks abuse Javascript.

But mostly because it's usually unnecessary and smacks of laziness on the developer's part.

Because you've literally just described what a <button> is.

That would mean that anything that responds to click events is a button. From your experience of using UIs, you can probably think of many more UI elements that respond to clicks and are not buttons