I'm going to maybe out myself as having limited experience here ...

I don't mind the idea here, seems good. But I also don't move a block of code often and discover variable assignment related issues.

Is the bad outcome more often seen in C/C++ or specific use cases?

Granted my coding style doesn't tend to involve a lot of variables being reassigned or used across vast swaths of code either so maybe I'm just doing this thing and so that's why I don't run into it.

In Python, no user object is modified by a simple assignment to a name. It just binds it.

It is not about mutable/immutable objects , it is about using a name for a single purpose within given scope.

    a = 1
    b = 2
    a = b
"a" name refers to the "2" object. "1" hasn't changed (ints are immutable in Python). If nothing else references it, it might as well disappear (or not).

Though both "single purpose" and immutability may be [distinct] good ideas.

So essentially he gives 2 arguments:

1) You get intermediate results visible in the debugger / accessible for logs, which I think is a benefit in any language.

2) You get an increased safety in case you move around some code. I do think that it applies to any language, maybe slightly more so in C due to its procedural nature.

See, the following pattern is rather common in C (not so much in C++):

- You allocate a structure S

- If S is used as input, you prefill it with some values. If it's used as output, you can keep it uninitialized or zfill.

- You call function f providing a pointer to that struct.

Lots of C APIs work that way: sockets addresses, time structures, filesystem entries, or even just stack allocated fixed size strings are common.