Oh another reason for my reluctance-
If it requires more code to implement the eye candy, then that's more code to maintain and debug and more opportunities for something to go wrong. For that reason I'd sooner shy away from the extra work, unless my client specifically want that feature and is willing to pay for the extra overhead associated with it.
datAdrenaline mentioned TreeView and ListView, which IINM, is pretty much Windows-standard in terms of look, so that's fine and dandy by me, especially if the client asked for that.
Most of time, my dealings with UI is actually spent getting it to act like Windows! One notable example is how Access's textbox (with multi-lines enabled) doesn't display scrollbars until it has the focus, which is slightly different from standard Windows textbox control which allows you to have the scrollbars always displayed but grayed out if the text doesn't expand beyond the textbox's dimensions. That was quite glaring to me because if users saw the textbox without scrollbars, they are more likely to assume that the text is all that there is.
To that end, there was two workarounds and both I wasn't quite too happy:
1) Use Common Forms 2.0 Textbox which behaves exactly the way as any other Windows textbox does but does not inherit the Windows theme. Therefore in an application where Windows theme is applied, it looks quite out of place and um, fugly. It does work, however, when the Windows theme is disabled via the Access's Option but that just makes the rest of application look "outdated", which unfortunately, is one of thing I don't really like to give up on.
2) Size the textbox so that the last line is halfway the text's height, so users can see that there is some text on the bottom and "clue" them to try and select the textbox and hopefully by then they'll have discovered the scrollbars and scroll down.
3) I said two but there is third that has been posted; I *think* Leban has a sample, but you can get a bitmap of scrollbar and paste it over the text box control, but 1) that is quite complicated way, 2) each bitmap would have to be resized for different textbox height. I'd hate to think of future users asking for a bigger textboxes! and 3) I'd have to add a fair amount of code to toggle the bitmap on and off so the normal scrollbar can be interacted with. In short, lot of work for little gain.
Anyway, with that in mind, this is a big reason, along with before-cited reason of consistency, why I'm reluctant to design and support fancy eye candies, though I know few would disagree with me and want their forms to be colored, laid with images or some snazzy buttons or whatever.
What matters to me the most is that the UI is clear and easy for users to understand. To borrow Apple's philosophy, users don't read the manuals and therefore, the application should not rely on them reading the manual.