Можливістю описати її безпосередньо у виразі (менше макаронності в коді, економія імен). Лямбда-костиль для let також часто потребує кількох інструкцій.

З цього випливають безліч проблем таких, як те що всі альтернативні реалізації інтерпретатора робляться в основному під Python 2

Ну це ж не PHP, щоб бути ідеальним.
Як можна в часи PHP, писати на вбогому путоні? Не розумію.

Зате Python простіше перетворити на LISP 

Відволічімося трохи від ліспу й погляньмо на сі-подібні мови (такі як C, C++, Java, PHP). У них є досить прикольний цикл for, яким можна не лише перебирати діапазон чисел, а й задавати довільні дії при ініціалізації, перевірці умови та переході на новий цикл. Пітонівський for є аналогом foreach, що робить його не менш крутим, але дещо менш універсальним. В принципі, сішний for є надлишковим, його цілком можна замінити на while з попередньою ініціалізацією (що здебільшого й роблять пітоністи в аналогічній ситуації), але такий підхід не дає доступу до деяких інших пітонівських фіч, пов'язаних з for (маю на увазі генератори колекцій — конструкції виду [f(i) for i in...]).

Коротше, мій костиль і кілька прикладів його застосування:

def cfor(first=0, cond=lambda x:True, step=lambda x:x+1):
    x=first
    while cond(x):
        yield x
        x=step(x)
        
if __name__=='__main__':
    print (list(cfor(1, lambda x:x<=30, lambda x:x+2)))
    print (list(cfor((1,1), lambda x:x[1]<10, lambda x:(-x[0],x[1]+1))))
    print (list(zip(cfor(step=int.__invert__), 'qwerty')))
    for i in cfor():
        if i>10: break
        print(i)

Функція сfor за заданими параметрами генерує ітератор, який можна використати як у циклі for (роблячи його функціонально подібним до сішного for), так і будь-де.

Перезавантажувані функції. Декоратор та приклади його використання

def overload(f):
    def decor(f1):
        def call(*args, **kwargs):
            try:
                return f(*args, **kwargs)
            except TypeError:
                return f1(*args, **kwargs)
        call.__doc__=f.__doc__
        return call
    return decor
        
@overload(overload)
def overload(f1, f2):
    return overload(f1)(f2)
        
@overload(overload)    
def overload(f1, f2, *fs):
    return overload(overload(f1, f2), *fs)

if __name__=='__main__':
    def fn():
        print('no args')
    @overload(fn)
    def fn(x):
        print('one arg:', x)
    @overload(fn)
    def fn(x, y):
        print('two args:', x, y)
    @overload(fn)
    def fn(*args, **kwargs):
        print('many args:', args, kwargs)
    fn()
    fn(10)
    fn(10, 20)
    fn(1, 2, 3, a='q', b='p')
    f=overload(
        lambda x:       x,
        lambda x, y:    x*y,
        lambda x, y, z: x*y**z)
    print(f(10), f(2, 3, 4), f(3, 3))

Власне перевірку типів аргументів декоратор overload не здійснює — лише послідовно намагається викликати всі версії функції, починаючи з першої, доки список параметрів не виявиться сумісним. Втім, оскільки для перевірки він відловлює TypeError, ніщо не заважає нам зробити перевірку типів усередині функції й викинути TypeError, якщо тип не підійшов.
Недоліком такого підходу є непередбачувана робота функції, якщо невідловлений TypeError виникне в її тілі — цього слід уникати.

Тим, що нам не треба руками писати if len(args)==2: ... elif len(args)==3 і т.д., менше мороки з видобуванням аргументів у кожній гілці. Загалом, це дає приблизно такі ж синтаксичні можливості, що й у Scheme чи Clojure

Можна винести їх у модуль, а тоді робити імпорт — у чому проблема?

Власне, overload з кількома аргументами непотрібен, якщо ми використовуємо його лише як декоратор.
Просто мені здалася цікавою ідея зробити сам overload перезавантажуваним, а заодно заімплементити варіант overload для роботи з кількома лямбдами (як в останньому прикладі).

Як це рятує у випадках, коли різні набори аргументів вимагають різної роботи функції?

Див. вище. Портування коду, написаного на Clojure. Щодо «не призначена» — Python же ніби багатопарадигматичний, у т.ч., включає можливості ФП — то чом би для даної задачі не використати їх, трохи доповнивши?