Here's one reason why not: no anonymous functions longer than one line. Which is a pretty lame limitation for a modern high-level language, all due to the dumb whitespace-as-scope design.
Honest question: If you are making an anonymous function longer than one line, shouldn't you just make a normal function? What are the use cases for large anonymous functions?
Especially in a learning context, I have no problem with requiring decent names for functions.
It's a learning context, not a professional one. This strikes me as like complaining that your carpentry class won't be covering a particularly exotic tool only favored by a quarter of professional carpenters anyhow. No, it's not a fatal objection to the class. If the tool is so wonderful they'll find out about it later. After they've become familiar with things like "hammers" and "nails" and the pounding thereof, which is the real problem they face today.
I wrote a nonblocking library (for pipes/processes/signals) in Python like node.js. So many of the callbacks end up being inner functions (they don't when you decide you can make all the necessary state object-level, and thus make the callback a method).
The anonymous syntax actually reads better than defining an inner function and then calling it.
I think the real reason why they were never added is syntax, and honestly I can't think of a good syntax myself.
In JavaScript, a broadly comparable language, I mainly use anonymous functions for event handling and map/each/fold. They are also useful for implementing more advanced code like arrows cleanly.
In a lot of ways the anonymous function in these cases is more akin to a block than a named function--it's only used once and in a very clear place. Having to name my click and onload handlers would make the code more confusing.
Coincidentally, this brings me to something that annoys me in both languages: lambdas are too verbose. Having much simpler and more concise lambda syntax (I'm personally a fan of Haskell's \ x -> x because it looks like a lambda if you squint) would make a lot of common idioms more readable and would encourage wider use of custom control abstractions, which can significantly improve code.
Amusingly I don't find myself using lambda syntax nearly as much in Haskell despite the fact that it looks really nice. A surprising amount of the time simple point-free code is all that's needed, and anything too complex gets moved into a where clause. But Haskell is not really comparable with JavaScript/Python at all.
>>> f = lambda x: (x
>>> f<function <lambda> at 0x108cf3230>