Oh please. You can "do" functional programming just fine in Python. If it's longer than a line, give it a name. It's not hard and it makes the code more readable and easier to maintain.
I do most of my work in multi-paradigm languages–so it's not like they're specifically designed around the ergonomics of working with functional programming–but Python is probably the worst language that I have used that could reasonably say that it supports this style of work. It's like it actively tries to make things strange and annoying to convince you to use other constructs (such as list comprehensions). Why can't I have a multiline lambda (…some things have no need for a name)? Why are all the functional methods free functions that take the list as the second parameter? Why was reduce arbitrarily excised from the list of built-in functions and put inside functools? Why can't I use a member function or operators as parameters without hacks like operators.__{operator_thats_a_reserved_word}__? Why do all the Python 3 functions return generators by default, when Python never really cared much about performance in the first place? It's just a death by a thousand cuts that always makes me regret even trying to do functional programming, and deep down I actually think the Python authors just don't want you do be doing it because they think it would lead to what they believe is difficult-to-understand code. Honestly, I think even C++ has better functional programming constructs than Python, even with its ugly-looking lambdas and lack of chaining, because <algorithm>'s extensiveness makes up for some of the language's warts.
In defense of Python, at least it supports closures that easily refer to variables higher up in the stack, whereas in C++ you always have to think about the lifetime of variables. Your other points I agree with.
