You're the second person in the recent past to call this to our attention. The "this" is that the default ring behavior isn't what people want from ASK.
But ASK is a special case. To understand the behavior of rings and variables, think about any other block with a ringed input, e.g., CALL or MAP. In those non-ASK cases, what does the user mean when they drag a variable into the ring slot? Almost always, it means that the value of the variable is an expression or a script, and the user wants to run that expression or script. For example, here's how you can write MAP in Snap!:
Look how FUNCTION is used both in the CALL block and in the recursive call to MAP. The value of FUNCTION is the expression that the user gave to the toplevel call to MAP. And it's that expression that you want to run. Therefore, we should evaluate
the variable reporter, not encapsulate it in a lambda.
The goal is that unsophisticated users should be able to use and write higher order functions with minimal emphasis on anonymous procedures. Snap! should just "do the right thing" for such users.
And yes, there are very occasional cases in which someone really does want to ringify a variable that's the input to CALL or MAP, but they really are quite rare, and the people who write code like that are sophisticated Snap! users who know about "ringify."
Except for ASK. In ASK it's common to want to know the value of a variable in the other sprite. So maybe we should have a special case for ASK and not unringify variables in the ringed input. (Just ASK, not TELL, because a variable reporter is an expression, not a script, so it's not a valid input to TELL.) Or maybe we should make the special case even more special by not unringifying only if the variable is a sprite-local one?
On the other hand, you can get the value of another sprite's local variable directly by using the OF block in Sensing. Once you've selected the sprite in the right pulldown, the left pulldown will include that sprite's local variables.