Matter of design, if you read out the OS colors and use them, you should be fine. In other situations it doesn't matter much.
Which is messy as far as maintaining cross-platform integrity is concerned. Also, even if you are programming for Windows only and decide to use GetSysColor(), it will only get you so far as Windows controls are now drawn by the theme engine, with textured background for buttons etc. The only way that you can access this is through more API commands, and by passing in a drawing context (hdc). It isn't really a "canvas" based gadget, anymore, is it?
> They are usually quite slow.
Then they're coded badly.
Then they're coded badly.
It's not necessarily that they are coded badly, but they have to use drawing procedures that aren't optimized for this purpose. OS control drawing is heavily optimized, for example, most Windows controls retrieve update regions, and clip drawing to them to improve painting times.
> They tend to be very buggy.
Then they're coded badly.
Then they're coded badly.
That goes without saying. ;-) Although, it's not necessarily because of lazy programmers! Canvas gadgets usually can't behave exactly the same as similar OS controls, and tend to miss out expected functionality in the OS (e.g. tabbing through controls to change focus).
Ultimately, canvas based gadgets have their uses (for drawing controls that don't pretend to act or behave like similar standard windows controls), but you should never pretend that they are anything similar to the native controls.