I won't go into a long justification (yea, right), but it works
for me. There may be advantages for locals, but for me, having one
variable name which has a one-to-one correspondence with same value
makes it easy for me to keep everything in mind. If I am debugging
and wonder what a variable is at any point, I know its name/symbol,
and a quick Debug.Print lets me know. Of course I can use the same
symbol for the local, but that seems to only complicate it for me.

I don't think I have a problem with unplanned variable changes.
To be honest, my biggest problem is not yielding to the lure of going
straight to the keyboard.
My standard [espoused] technique is to flow-chart (one page) the
routine first and get that working for the universe of inputs
expected, and unexpected. The coding then becomes only an exercise in
typo correction. The flow chart also makes debugging, enhancements
and maintenance a snap. Once the lower level  routines are
bullet-proof, I get closer to a "main" program  which looks more like a
list of subroutines (and the flowchart).

Most time, for me, is spent designing the error handling -
deciding what the bad  inputs can be, which I want to handle and what
the user can do that will mess things up. { "You can't make it idiot
proof, because idiots are too damned ingenious."} I also develop a
test regime and run it through the ringer.
I believe the biggest area time-wise, should be spent addressing
the "User Hostility Factor".

I get OO basics, but my mind still thinks in linear programming.
Coming from the old school [assembler, Basic], I still have a hard
time with VB / OO *in practice*. The object model is significantly
different and VBA has it's own confusion factors. Planning is the key.

I *was* trying to steer the neophyte OP to reading up on the basics on
scope and variables.