First, I think a better name for what you are asking about is mouse pointer, not mouse cursor. For me cursor evokes the mouse-unrelated text input positioner (as in the Terminal or text editor cursor that you move around with the cursor keys).
Why isn't the pointer choice on clickable areas a Pointing Hand Finger which suggests an area to click on?
Apple wants to reserve custom pointers (other than the text input pointer and the resize window or element pointers) to significate modes within your app, not clickable areas. I guess that the hand pointer is still ubiquitously used in web because at the beginning it was hard to tell hyperlinks from regular text.
From OS X Human Interface Guidelines (I suggest you read them on their entirety before starting to code apps for OS X):
Clearly indicate the current mode. If users can enter different modes
in your app, make it easy for them to tell at a glance which mode
they’re in. For example, a graphics app might use different pointer
styles to indicate whether the user is currently in drawing, erasing,
or selection mode. A segmented control can also show which mode the
user is in; for example the View segmented control in the Finder
toolbar indicates whether users are in icon, list, column, or Cover
Flow view. And a popover offers a very strong visual indication of a
self-contained task. (To learn more about using a popover in your app,
see “Popovers.”)
My best guess is that Apple believes (correctly in my opinion) that the user does not perceive things like toolbars or tab bars. The user perceives tasks he wants to accomplish within your app. The app provides means to accomplish these tasks. Apple doesn't want your user to think that he is using buttons. Apple wants them to use the buttons instinctively.
Now you could say: "But this change in pointer helps the user knowing where he can click on and where he cannot". To that I respond: launch iTunes 11, Xcode 4, Final Cut Pro X, or even Finder. Look at all of these apps and try to decide where the pointer should show a hand and where it should show an arrow. My guess is that you won't reach a satisfactory answer.
There is a myriad of conceptually different clickable elements:
- regular toolbars with buttons
- sidebars in which you change the main view by changing the sidebar selection
- informative displays (labels mostly, but sometimes they become compounded controls) which the app updates when it is performing an operation. They become clickable only when there is an operation going on; clicking gives you more information about this operation.
- navigation-bar/drop-down-menu hybrids (e.g., Xcode scheme selection and file selection nav bars)
- tabs
- ...and more.
After looking at all this some possible "solutions" could be:
Show a hand for all clickable elements!
Then you show a hand most of the time, why show an arrow at all? In addition, a little arrow is better for pointing than a little hand. See below for more comment on this.
Show a hand only for toolbars (or only for type Y of clickable elements)!
In Apple's mind there are no toolbars, there is your application that does things in different modes. Maybe toolbars make sense for one kind of application but not for others. The fact that toolbars are not mandatory at all precludes for a feature like this to be an OS-wide UX guideline.
Add a new different custom cursor for each different type of clickable area!
This is more confusing than helpful and breaks the "custom cursors significate distinct app modes" model.
Should I opt for that or stick with Arrow cursor on my own applications user interfaces?
I would not opt for what you suggest. Users accustomed to the OS X way will wince at your app if you do this.
If the applications' UIs are heavily customised (ie. skinned-themed), should cursor choice differ or stick with OS defaults?
I would not for the same reason as above.
But I still want to show the clickable areas of my app with a different cursor.
If you want to go for this, what I would do is keep the arrow pointer for everything. Just dim it slightly (maybe 10% opacity loss or a similar effect) on non-clickable areas. I have never implemented nor used an app that does this. I would need to use this to see how it feels before fully endorsing this solution. If implemented properly I can see it being a subtle and elegant way of hinting at clickable elements.