I'm not sure on the hard numbers, so please take this with a grain of salt as your mileage my vary, but I have found that if you can replace two draw_* functions with a single texture, then it's more performant to use a texture.
I think this is because it's slightly more expensive to call 2+ draw_* commands than just drawing a single texture because of the CPU to GPU communication rather than the drawing itself. I think it may also slightly vary based on how often you are drawing the textures from scratch though, as draw_* functions will save the result until update is called again, making it very fast after the _draw function been called once.
I had a working prototype similar to the indie game INK that used draw_* functions to make the ink splats and I found that the biggest performance bottleneck with using draw_* was going through and updating all the ink splats, as after it got about 2 thousand splats large, it was calling the draw_* functions that was causing performance issues rather than drawing itself. To work around it I just spawned "managers" that would handle drawing 2 thousand splats, and then when a manager was full another would be spawned and new splats would draw there instead. Since I didn't need to dynamically remove splats, keeping old managers around with their cached draw results worked fine for the prototype.
So that is to say, I think textures are slightly faster if you can cut down on CPU to GPU time, but I think that is the biggest difference, at least that I have seen. If you have very large images with lots of transparency, using draw_* might work better on mobile platforms, as they can have some slowdowns due to large transparent images and processing.
Shaders are probably the fastest of the bunch, but I'm not sure. It would run on the GPU and might be able to run in semi-parallel, so that is probably where shaders would get the majority of their performance boost compared to textures or draw_* commands. I'm not sure how much faster it would be though.
