I’m assuming that cursor: pointer is the optimal value for standard button elements (<button> and the like), from an usability standpoint. However, user agents don’t default to this value and sites like Google Search even enforce cursor: default for the main UI buttons.
Is there a usability best practice for this?
This reminds me, the results of normalize.css should all be added to the HTML Specification as part of the standard (with all divergences officially becoming bugs in the form of spec violations). I have normalize.css as the one mandatory external resource of my HTML boilerplate on any project I start, and I didn’t even realize this wasn’t shipping as part of the base stylesheet until you mentioned it.
The HTML spec already standardizes certain default styles, doesn’t it? It would be interesting to see a comparison between these standard defaults and the additional rules from Normalize.css. This research is also a necessity, since each additional default style has to be standardized individually anyway.
cursor: pointer is (similar to text-decoration: underline) typically reserved for links while buttons and links are different things (a link points to a location while a button performs some action).
Given that forms, unlike links, cannot typically be submitted to e.g. new tab with Ctrl+Click, using cursor: pointer for buttons could be somewhat confusing, though this is probably mostly theoretical since buttons in forms are usually quite obvious to act as buttons, not as links, and also given that lone buttons sometimes used as links.
I appreciate the distinction, but today, the notion of “actions” versus separate “locations” is so blurry, I don’t feel the distinction is more worth making to the user than the distinction between “hit targets that do something” and “hit targets that don’t do something”.
I agree with @stuartpb: The distinction is correct, but I don’t think that it matters to most users. cursor: pointer is often used for something you can press on.
Also, if we want to distinguish between types of click that result in different actions, we should be using more types of cursor (as I believe KDE/Konqueror did/does). On that note, does the cursor CSS property accept multiple values for fallbacks in the event the system doesn’t recognize a value, akin to the way font-family works today? I shouldn’t have to figure out UA style matching if I want to support a future with more cursor types (eg. cursor: pointer-link, pointer or cursor: pointer-link, url('pointer-link.png')).
The spec currently allows fallbacks for image cursors, but only one keyword value can appear, so pointer-link, pointer is not possible.
In the absence of anything better, there’s always the @supports syntax, e.g.
.thing {
cursor: pointer;
}
@supports (cursor: pointer-link) {
.thing {
cursor: pointer-link;
}
}
Unknown values make the declaration be dropped, so just do cursor: pointer; cursor: pointer-link;
Besides semantic, what would be a practical difference between pointer, and pointer-link?
As an answer to the original question, I’ll also add that desktop operating systems don’t use a “hand” cursor for interactive elements: buttons, menu entries, etc. The hand cursor is fairly specific to hypertext links.
Not sure why websites would be different. If you want to convey, on mouseover, that elements can be clicked, you should use a hover style variation (like desktop OSes often do), and you should probably apply the same variation on :focus as well. If you think your users would be confused by the lack of a “hand” cursor (which is a debatable assumption), you can of course be opinionated like normalize.css is on this topic:
/**
* Change the cursor in all browsers (opinionated).
*/
button,
[type="button"],
[type="reset"],
[type="submit"] {
cursor: pointer;
}
Some user agents display a 
icon next to the pointer for hyperlinks (like I said, I think I’ve seen this in KDE/Konqueror).