Adding e.g. a symbolic constant is a bet. You win if during the lifetime of the system, you discover that the constant must be changed, and the gain is the time saved by changing it quickly and with few errors. If you never have to change the constant, you lose the time spent on introducing the constant and the time spent on looking up the constant while reading the code.
Most of the rules here are long change (or whatever the financial people call betting on something), except for KISS.
I don't think these are rules of thumb that you should take for granted without criticism, especially when paraphrased from their original (well researched) source.
And I especially don't think you should take from them what you like. They are principles you should know because they are known to lead to well designed software, you should leave none of them alone.
The person you responded to mentioned novice programmers. Teaching novice programmers with the attitude of "use as much of this as you like/want/understand" is a pretty poor technique that will not give good results.