The problem is that you then have a function whose return value depends on where it is called. Not when, but physically where. Also, imagine the havoc that would be reached with a memoized function: if f were memoized, then its return value would change depending on where it was called first. You could certainly argue that you shouldn't memoize f, but I think that you would find that this cropped up with functions that were actually a good idea to memoize.
The problem with being able to change f's return value by wrapping it in a lexical scope is that it destroys the "black box" abstraction of a function. You have to know how f is implemented to get a certain effect; alternatively, if you don't know how f is implemented, a simple change of variable name could wreak havoc with your program.
Actually, that name-change issue reveals another problem with dynamic binding: dynamic binding, I think, destroys alpha-equivalence (a fundamental property of the lambda calculus: http://en.wikipedia.org/wiki/Lambda_calculus#.CE.B1-conversi...). It might even play with the ability to do beta-reduction, but I'd have to think about that one more.
Gah, same gotcha as before. Mea culpa. I still stand by the first two paragraphs, though; it may not be alpha-equivalence, but changing names should rarely, if ever, affect distinct parts of the program.
