Perhaps this analogy will help to understand why one should use \let\commandB\commandA before \renewcommand{\commandA}{...}.
If a file should be kept before accidentally modifying (deleting?) it, it should be stored to some other place or copied to another name, so a cp -a fileA fileB (with Un*x commands) is making the copy of the original file and naming it fileB. For a short while both files do exist and are identical.
Now fileA can be edited etc.
The same is true for \let..., but \let is not like a pointer in the C programming language, pointing to the same memory location or like a symlink in the file system.
First safe the definition of \commandA to some other name, say \commandB with
\let\commandB\commandA
This will be done immediately, i.e. \commandB has the same definition like \commandA and will do the same operation like \commandA.
- Now do the eventual change of
\commandA with \renewcommand{\commandA}{...} or \def etc.
This is a technique applied very often, in order to extent the definition of \commandA (i.e. before or after its code) to use its definition inside the redefinition, i.e. call \commandB to get the original effect.
Please note that for commands with optional arguments \LetLtxMacro from the letltxmacro package by Heiko Oberdiek should be used, not \let.
expl3 on the other hand provides \cs_set_eq:NN etc. commands.
\let\commandB\commandAoccurs before the redefinition of\commandA, then the original definition of\commandAis saved in\commandB– Steven B. Segletes Feb 09 '17 at 19:08\let\commandB\commandA, the meaning of\commandBdoes not depend on later modifications of\commandA. – egreg Feb 09 '17 at 19:10\NewCommandCopycommand etc. – user202729 May 20 '23 at 07:09