It can't literally be , since I know from my own code that using a BITMAP or an RLE sprite created from that bitmap do actually produce the same result when normally drawn. You should have mentioned you were using alpha channels though (or maybe I should have read your original post a bit more carefully and inferred it from there)!
When you construct the RLE sprite, it throws away the magic pink parts irrespective of the alpha value there (the docs are actually outdated in this respect because they say that "repeated zero pixels are replaced by a single length count"). When you then activate the alpha blender and draw the sprite, it will only look at the alpha value for the parts that it has retained - it cannot draw parts of the image it has thrown away. In other words, the image shows the expected behavior for the RLE sprite.
The normal bitmap is another matter. It is clear from that image that it only looks at the alpha value to determine transparency. This is in contradiction with the draw_trans_sprite() documentation, which states
As draw_sprite() this function skips transparent pixels.
For the alpha-blending mode, however, "transparency" is only determined by the alpha value (as per http://www.allegro.cc/manual/set_alpha_blender), so this is probably actually the intended behavior for alpha blending.
If anything, this is a bug in draw_trans_sprite(), not in the RLE sprite code. However, I think this more reflects a difference between RLE sprites and "normal" sprites than a bug in the code. You may argue that RLE sprites created after enabling the alpha blending mode should skip pixels that are invisible according to the alpha value rather than the mask colour (maybe it actually does this, but I don't think so), but I personally feel this makes things much more complicated for little gain. I don't think you have a case for RLE sprites created before enabling the alpha blender. I think the current behavior is actually consistent with the documentation, but the documentation doesn't make this clear enough. In other words, I think the documentation should be clarified rather than the code changed. Feel free to argue this point though.
One other thing: I vaguely recall something like this being discussed on AD at some point in the past few years. You may want to see if anything like that turns up in the archive (I can probably do that more easily from my local mailbox at home than through the SF archive, but I won't be able to do that for a couple of days at least).