Symbols are notoriously ineffective as labels because they are very difficult to interpret properly without training or experience. In most situations, users learn the correct interpretation better with text than with symbols. See: Wiedenbeck, S. (1999). Using Symbols and Labels in an End User Application Program: An Empirical Study on Learning and Retention. Behavior & Information Technology, 18 (2), pp. 68-82.
Icons are especially poor for abstract objects such as "bill" or "bid" because abstract objects generally do not have a strong visual image (both "bill" and "bid" could be represented as paper documents, but how would you distinguish them? ). Likewise, icons are especially bad for actions (such as saving, publishing). It is difficult to clearly show a process with a picture. Yes, Toolbars are constantly using icons for actions. However, the toolbars were meant for experts, and yet users are often confused (on average, users only know six Word toolbar items after using Word for regular use) 2 years).
Icons can save space above the text, but at the price of recognition. For small symbols, eg. 16 x 16 pixels, it is very difficult for users to even know what they should be an image for, let alone what the image should stand for. One user I know thought the "floppy" icon to save was a picture of a TV. (She was old enough to know what a floppy disk is.) Personally, I used Word for years, thinking the change symbol was a kind of stylized Rosetta Stone. Experienced users can more easily rely on the stored physical location of the controls in the toolbar than in the symbol labels when selecting a control. Larger icons (for example, at least 32 x 32 pixels) can help detect them, but take up so much space that you can make better use of the space for plain text labeling. When space is limited, it is often better to use abbreviated text as symbols.
It is extremely difficult to find the right symbols. Do not try to develop a new icon without extensive user test iterations. Even then you can fail. The designers at Microsoft tried everything to create interpretable icons for the Outlook toolbar before they dropped text captions for key controls.
Icon labels also make it difficult to provide technical support (for example, "Click the yellow sheet with the blue check mark" versus "Click Accept.").
As a rule of thumb, only symbols should be allowed if at least two of the following three conditions are true:
The place is very limited (ie, too small for text alone).
The symbols are standardized (eg the disk image for saving).
The icon represents an object with a strong physical analog or visual attribute (for example, a printer icon to access printer attributes, or a red rectangle to specify a red page background).
Tooltips are needed for icons when used alone. However, they are a poor substitute for text captions. Your users should not have to use your app to search for things. The fact that text captions never need graphical tooltips is a pretty good indication that text is better than symbols.
If space permits, symbols in combination with text are best. (I believe there are studies that prove this from the late 1980s, but I can not find it.) By using symbols with text, certain elements can be highlighted or made visually more interesting. This can also improve the scannability of the elements, but good text labels can do that as well. It is well known that users subjectively consider an app to be simpler if it contains symbols, even though it does not actually improve performance (see Wiedenbeck, 1999, supra). This is another reason to combine symbols and text.
I usually see the icon either above or to the left of the text label. I do not think it's inherently better than the alternatives, but it's a convention that you should follow if you have controls side by side so that the user can rely on the experience of what text label to which icon fits.