I must admit I didn't go deep enough into the article you posted, Rodrigo, to fully understand it - but from what I understood, they pass a coordinate into a method, and it returns the alpha value of the shadow at that specific position. Which could be done inside a fragment shader, of course (although AGAL would make it a little difficult to write). It's worth noting, though, that old GPUs would have a hard time do all those per-pixel operations.
I guess it would be doable - but if it's worth investigating this further depends on how you're going to use the shadows.
Where this method is incredibly efficient is when you constantly change the (apparent) z-position of an object. I.e., you want a box to appear to move closer to the camera by offsetting the shadow and raising its blur-factor. Animating that is expensive with Starling's standard filters, because you have to redraw the multipass-blur again in each frame.
If, on the other hand, you mostly move the shape with the shadow along the x- and y-axes, you can always call "cache()" on the filter and it will be drawn with maximum performance (it's just a textured quad then).
What's more expensive is that each filtered object requires its own draw call. That would be the same with the mentioned algorithm, though, at least if you want to always have the drop shadow directly below the object that casts the shadow (in other words: drawn directly before that object, in painter's algorithm style).
So he "ramping" idea that John mentions would be a good alternative.
Another cheap and flexible way to draw lots of shadows would be to use a Scale9-Grid for the shadow, with the "ramping" going on in the corners and edges. If we're talking about a drop shadow of a rectangle (or rounded rectangle), you can easily put that in a scale9-grid. By changing width and height of the image, you manipulate the shape (i.e. portrait or landscape rectangle); to modify the blurriness, put that shadow in a sprite and scale that sprite. A helper class could make that rather easy to manage.
The main advantage of this solution: if the shadows are in the same texture atlas as the other interface elements, this could all be batched together. Which would solve the part of the rendering that actually is the bottleneck.