Here’s another way to say it:
Let’s say that you’ve got a solid-red object (RGB = (1.0, 0.0, 0.0)) with 50% opacity (A=0.5). (Let’s say for the sake of simplicity that the whole thing’s semi-transparent, not just the “anti-aliasing” border.)
The proper display color of that pixel would be (0.5, 0.0, 0.0), which is obtained by multiplying each color by the alpha (50% = 0.5). One way or the other, that’s the actual color that you eventually want to see on the screen for that little dot.
And, okay, you can do that floating-point multiplication “every single time with every single pixel,” but often that’s just an unwanted and unnecessary extra step. Therefore, you can perform the multiplication in advance … pre-multiply the RGB values with the alpha (which may or may not also be stored separately). Now, the RGB information will “look right” just by itself. Life is good.
As you see, the “correct” interpretation of a pixel such as (RGBA = (0.5, 0.0, 0.0, 0.5)) depends on knowing whether the value has been pre-multiplied or not … and, unfortunately, image files usually don’t say one way or the other. The effect of premultiplication, of course, is 100% reversible and Blender will happily do it or un-do it, but in your pipeline you have to (one way or the other) tell Blender what is the correct thing to do.
If you see a “halo” around an object, like this, you can be certain that what you’re seeing is the semi-transparent “anti-aliasing” border around the object, and that you’re seeing it merely because the premultiplication is at the moment being handled incorrectly.
There’s one other thing to remember about Alpha: not every image-file format stores it. (JPG doesn’t, PNG does, OpenEXR of course does, etc.) And, you must request that it be included by selecting the “RGBA” format on output.