Почему на переменную списка иногда не влияют изменения в функции, поскольку я думал, что python3 работает при передаче по ссылке с переменными списка?

Ваша конечная проблема состоит в том, что вы путаете (на месте) мутацию с повторным связыванием (также называемым несколько менее точно переназначением).

Во всех случаях, когда изменение не видно за пределами функции, вы переустанавливаете имя внутри функции. Когда вы делаете:

name = val

неважно, что раньше было в name; это восстановление к val, и ссылка на старый объект отбрасывается. Когда это последняя ссылка, это приводит к очистке объекта; в вашем случае аргумент использованный для псевдонима объекта также связан с именем в вызывающем объекте, но после повторной привязки эта ассоциация псевдонимов теряется.

В сторону для людей C/C++: перепривязка похожа на присвоение переменной указателя, например. int *px = pfoo; (начальное связывание), за которым следует px = pbar; (повторное связывание), где pfoo и pbar сами являются указателями на int. Когда происходит присваивание px = pbar;, не имеет значения, что px раньше указывало на то же самое, что и pfoo, теперь оно указывает на что-то новое, и следующее за ним *px = 1; (мутация, а не повторное связывание) влияет только на то, на что указывает pbar, оставляя цель pfoo не изменилась.

Напротив, мутация не нарушает ассоциации псевдонимов, поэтому:

name[1] = val

перепривязывает себя name[1], но не перепривязывает name; он продолжает ссылаться на тот же объект, что и раньше, он просто изменяет этот объект на месте, оставляя все псевдонимы нетронутыми (таким образом, все имена, использующие псевдонимы одного и того же объекта, видят результат изменения).

В вашем конкретном случае вы можете изменить сломанные функции с повторной привязки на псевдоним, изменив назначение/удаление среза или другие формы мутации на месте, например:

def func3(_in):
    # _in = list()  BAD, rebinds
    _in.clear()     # Good, method mutates in place
    del _in[:]      # Good, equivalent to clear
    _in[:] = list() # Acceptable; needlessly creates empty list, but closest to original
                    # code, and has same effect

def func5_no_ret(_src, _dest1, _dest2):
    # BAD, all rebinding to new lists, not changing contents of original lists
    #_dest1 = [val for val in _src[0:len(_src):2]]
    #_dest2 = [val for val in _src[1:len(_src):2]]
    #_src = list()

    # Acceptable (you should just use multiple return values, not modify caller arguments)
    # this isn't C where multiple returns are a PITA
    _dest1[:] = _src[::2]  # Removed slice components where defaults equivalent
    _dest2[:] = _src[1::2] # and dropped pointless listcomp; if _src might not be a list
                           # list(_src[::2]) is still better than no-op listcomp
    _src.clear()

    # Best (though clearing _src is still weird)
    retval = _src[::2], _src[1::2]
    _src.clear()
    return retval

    # Perhaps overly clever to avoid named temporary:
    try:
        return _src[::2], _src[1::2]
    finally:
        _src.clear()