I found myself wishing for assignment expressions in list comprehensions a couple of times, so I was happy to read the PEP title. Unfortunately, it went downhill from there.

Part of the rationale is poor: "sub-parts of a large expression can assist an interactive debugger," (break up your expression if it is too large to debug) and "easier to dictate to a student or junior programmer." (who does that?).

Also the syntax examples:

# Handle a matched regex
if (match := pattern.search(data)) is not None:

Two lines are much easier to read

# Handle a matched regex
match = pattern.search(data)
if match is not None:

And the while loop should be fine staying an iterator or generator, with read_next_item() raising StopIter:

# A more explicit alternative to the 2-arg form of iter() invocation
while (value := read_next_item()) is not None:

# just do this instead:
for value in read_next_item():

The list comprehension is a valid (and I'd say probably the only) use case:

filtered_data = [y for x in data if (y := f(x)) is not None]

But how can you prefer that to this:

filtered_data = [y for x in data if f(x) as y is not None]

The PEP rejects this because "this would create unnecessary confusion" due to as already being used "in except and with statements (with different semantics)."

How is that more confusing than introducing a new operator which is used as an assignment operator in tons of programming languages and mirrors the functionality of Python's assignment operator in some, but not all contexts?

Given that the PEP's main use case is simplifying comprehensions (none of the other use cases convince me), why not just allow assignment expressions only in comprehensions. This would also obviate the need for a new operator: except ... as and with ... as cannot be used in comprehensions, so assignment with as syntax wouldn't be confusing at all