Why don't <button> HTML elements have a CSS cursor pointer by default?

Here's why:

Microsoft’s design guides talk about weak affordance:

Text and graphics links use a hand […] pointer […] because of their weak affordance. While links may have other visual clues to indicate that they are links (such as underlines and special placement), displaying the hand pointer on hover is the definitive indication of a link. To avoid confusion, it is imperative not to use the hand pointer for other purposes. For example, command buttons already have a strong affordance, so they don’t need a hand pointer. The hand pointer must mean “this target is a link” and nothing else.

Apple’s Human Interface Guidelines states that the hand cursor should be used when “the content is a URL link”.

W3C User Interface guidelines says the same thing again with “The cursor is a pointer that indicates a link”.

From "Buttons shouldn’t have a hand cursor" by Adam Silver

According to W3C cursor:

pointer The cursor is a pointer that indicates a link.

The specification only indicates that links are meant to have the pointer cursor. Buttons are not meant to have the pointer cursor in the specification and probably that is the reason why Browsers don't assign it by default and we have to do it manually.

As to why would links need the pointer cursor, additionally to Dipak's answer, my understanding is that the specification considered it might not be obvious (in comparison with the surrounding text) that text links are links.

It's worth considering the historical order in which these things came into being.

Buttons existed from very early in the days of GUI computing. They had a shadowing effect to give a skeuomorphic impression of their being akin to physical buttons, which served to indicate they could be clicked much as one would push such a physical button. Indeed since you could be clicking a physical button on the mouse to do so (assuming you weren't tabbing on the keyboard to navigate), the skeuomorphism was backed up by that physical action.

When the cursor was over them they got the default cursor that indicated that while it may be possible to click or double-click whatever was under the cursor, they couldn't be typed in, and nor where they the dragging edge of a resizable object. Mostly the fact that they looked a bit like physical buttons sufficed to indicate that they were clickable.

When hypertext (of which the web isn't the first, but was the killer app that brought it to a wide audience) emerged the clickable bits of text were indicated through underlining and (when colour was available) different colours to the non-linked text. It was still relatively weak as a physical signal so the hand-shaped cursor was used as a further indication.

It was some time before <input> gave buttons when the type was submit or reset. Like the other types of <input> they were implemented through the mechanisms the OSs had for standard widgets and would have standard buttons. As the OSs put arrow cursors on such widgets, they had arrow cursors. That was fine as within the relatively limited range of features one could have in a web page at the time went, they were obviously buttons and obviously clickable. It would also be a bit weird to have anything other than normal OS behaviour at the time, since it would mean that web-browsers were acting strangely compared to other programs. If even many richly formatted applications (like games and some high-end office software which customised UI features beyond the OSs' standard) used arrows here, why wouldn't a relatively boring thing like a web page, which is just some black on grey text with some blue bits and maybe a few images floating to one side or the other?

When CSS made the presentation opportunities for web pages much richer (though they already had colour and font choices by now, albeit in horrid to code ways) buttons were still being rendered by calling into the OSs windowing system calls, so not affected by CSS. When CSS later made cursors one of the things that could be changed for an element, buttons weren't affected as they were outside of the scope of what CSS could change.

Browsers started drawing their own buttons so that CSS could change the appearance and also so they wouldn't "shine through" elements positioned "above" them in layered effects, but by now there was over a decade of the hand cursor being the normal cursor for a link and an arrow cursor being the normal cursor for a button. Even if one would argue now that buttons in browsers are no longer the same thing as buttons in other applications (which is a questionable argument still), consistency argues against such a change, particularly as the default; okay it would be technically easy to change it now, but it's technically easy for the page designer to change it now too, so why change the appearance of the pages of the people who haven't decided they want to change it?

First, <button> is not a link so any answers ascribing to what happens when you hover over a link don't apply. Second, CSS is a separate, independent specification from HTML. One does not specify what the other should do. It is the browser vendor that decides what CSS is provided for any actions in many cases though they tend to stick to the same thing if it's not in the specification.

It's been a long time since I've read this part of the spec and I'd have to review it for what is there but I'm pretty sure there is an indication nothing is to happen in this case because a button should be a button and if it's not a button it should be something else!

- Used for most objects. - Used for text links.

Example of a mouse pointer

Hover cursor change in the animated picture to the right is an example of a mouse cursor moving around the screen as a pointed arrow, over text as an I-beam cursor, and then hovering over a link as a hand pointer.

Concluzion:

Mouse arrow is destined for selecting of most objects (like button)

Hand pointer is destined for selecting an object or text links