Hey dude. Interesting examination. It’s been a long time since I thought about this…
It’s worth noting that— like menus, tabs, browser buttons, etc— form controls were originally much more “native” than their surrounding HTML elements. The HTML spec simply required a specific functionality, but left the exact implementation up to the browser maker to determine. Is that why form elements get the regular arrow pointer? I’m not sure, but it’s worth mentioning.
Regarding minimizing the use of the hand cursor, I’m not sure it’s so black & white. To the common man/woman, I think we’ve come to recognize it as a distinction between HTML and native (and plugins like activeX and java— OGs represent!). There’s something oddly comforting about having this distinction. Even the best crafted button with obvious affordances, “feels” like it should have a hover cursor in a HTML context. It feels right in the same way that a floppy disk icon feels right for representing save.
That said, the lines are slowly getting blurred as HTML technologies continue to become more pervasive in the app development world. I believe the distinction is shifting to webpage vs [web]app. Webpages will continue to own the hand cursor to indicate hyper-text “document” and inter-linked-ness, while [web]apps will fully adopt the normal arrow pointer to indicate high-level functionality. For a great example of this already playing out, compare the Google Docs browsing view to the word processing view.